Every few months a client asks me whether they should build their document layouts in the Acumatica Report Designer or in BIRT, usually because a developer on their team knows BIRT from a previous ERP (it ships as the default reporting tool with several systems). The honest answer is that inside Acumatica this is rarely a close call — but the reasoning is worth writing down, because the same reasoning applies to any external reporting engine you might bolt on.
What each tool actually is
The Acumatica Report Designer is a Windows desktop application that produces .rpx files. An .rpx is an XML definition — schema, relations, parameters, layout sections — that the Acumatica server renders natively. Reports deploy inside customization projects, appear in the sitemap, respect access rights, print from processing screens, attach to email templates, and can be invoked from graph code via PXReportRequiredException.
BIRT (Business Intelligence and Reporting Tools) is an Eclipse-based open-source engine. It knows nothing about Acumatica. To use it you point BIRT at a data source — for Acumatica that realistically means the OData feed over a Generic Inquiry, the contract-based REST API, or (against all advice for SaaS instances) a database connection you do not have. BIRT then renders and distributes reports entirely outside the ERP.
That asymmetry drives everything: one is a first-class citizen of the platform, the other is an external consumer of its APIs.
Where the embedded Report Designer wins
- Transactional documents. Invoices, sales orders, purchase orders, statements, picking lists. These need to print from the document screen, respect the current company's branding per branch, attach to the email activity, and version with your customization project. BIRT can technically produce an invoice PDF, but wiring it to the "Print Invoice" action means custom code calling an external service — pure liability.
- Security for free. An
.rpxreport runs under the requesting user's session: branch security, restriction groups, and row-level security all apply. A BIRT report runs under whatever integration credential you gave it, which is usually broader than any single user. - Multi-tenant and localisation. Report Designer picks up the tenant's base currency, number formats, and can be localised with Acumatica's translation dictionaries. You rebuild all of that by hand externally.
- Deployment. Reports travel in the customization package with everything else. Your CI/CD pipeline for Acumatica already handles them.
Where BIRT (or any external engine) has a case
I will grant BIRT three legitimate scenarios:
- Cross-system reports. If the report joins Acumatica data with a warehouse-management system and an e-commerce database, the ERP's designer cannot help you — its data source is Acumatica DACs, full stop. An external engine querying multiple sources is the right architecture. (Though in 2026 I would reach for Power BI or a small Laravel reporting service before BIRT.)
- Existing BIRT estate. A team migrating from an ERP with fifty polished BIRT layouts and deep BIRT skills can defensibly keep the engine and repoint data sources at Acumatica OData feeds during transition. Budget for rework anyway — the data shapes never match.
- Very heavy scheduled output. Rendering thousands of large PDFs on a schedule competes with interactive users for app-server resources. Offloading bulk rendering to an external engine reading from a replica or OData keeps the ERP responsive. Acumatica's own scheduler handles moderate volume fine; this matters at the extreme end.
On SaaS you cannot, and on private cloud you should not point BIRT at the Acumatica database. The schema is an implementation detail: CompanyID discrimination, DeletedDatabaseRecord flags, and denormalised balance tables will produce confidently wrong numbers, and upgrades will break your queries without notice. Go through a GI + OData so the platform applies tenancy and soft-delete filtering for you.
The decision in one table
| Requirement | Report Designer | BIRT / external |
|---|---|---|
| Invoice / PO / document print | Yes — always | No |
| Runs from a screen action or workflow | Yes | Only with custom glue code |
| User-context security required | Built in | Rebuild it yourself |
| Joins non-Acumatica data | No | Yes — its actual strength |
| Pixel-heavy analytical packs | Workable but tedious | Comfortable |
| Team already owns the tool | Learnable in days | Legitimate transitional reason |
Practical advice if you keep both
Some clients end up with both engines, and that is fine if you draw the line clearly: documents and anything security-sensitive live in Report Designer; cross-system analytics live outside. Publish the external reports' data through named Generic Inquiries with Expose via OData, one GI per report, so you can see exactly what each external report consumes and can version those GIs deliberately. Give the external engine its own API user with rights scoped to those GIs and nothing else.
And resist the temptation to route around Report Designer because the desktop tool feels dated. It is dated — it is also the only tool that renders inside the security and deployment model you already paid for. I have replaced more than one BIRT-based invoice pipeline with a plain .rpx and deleted a Windows service, a cron job, and two credentials in the process. Less moving machinery, fewer 3 a.m. calls.
Wrapping up
Use the embedded Report Designer for everything that lives inside Acumatica's workflow — which is nearly everything a typical implementation needs. Reach for BIRT or another external engine only when the report genuinely spans systems or the rendering load genuinely needs to leave the app tier. When you do go external, consume GIs over OData, never the raw database.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.