Acumatica Report — SSRS vs Embedded Designer

Teams coming to Acumatica from Dynamics GP, NAV, or a homegrown .NET stack almost always arrive with a folder of SSRS reports and a developer who is genuinely good at SQL Server Reporting Services. The question lands on my desk in the same form every time: "can we keep using SSRS, or do we have to learn the embedded Report Designer?" You can keep SSRS. Whether you should depends on which of two very different jobs the report is doing.

Documents versus analytics: two different jobs

Every report in an ERP is one of two things. It is either a document — an invoice, a purchase order, a statement, a picking list — that must print from a screen, respect per-branch branding, attach to emails, and participate in workflow. Or it is analytics — a margin pack, a trend analysis, an operations dashboard — that someone reads to make a decision.

The embedded Report Designer owns the first job outright. Its .rpx reports are invoked by the platform itself: the Print action on the Invoices screen, the PXReportRequiredException you throw from a graph, the mailing settings on the Customer class that pick a report ID for statement runs. SSRS cannot participate in any of that without you writing and maintaining glue code — a web service call, credentials, error handling, retry logic. I have inherited two such glue layers from previous vendors and decommissioned both.

For the second job the calculus genuinely differs, so the rest of this post is about analytics.

How SSRS gets Acumatica data (and how it must not)

SSRS wants a data source. Your realistic options against Acumatica, best to worst:

1. OData over Generic Inquiries. Build a GI shaped for the report, tick Expose via OData, and consume https://instance/odata/GIName (or the OData v4 endpoint on current builds) from SSRS with an XML/OData data source or via a small ETL step into a reporting database. Tenancy, soft deletes, and business logic filtering are applied by the platform.
2. Contract-based REST API into a staging database that SSRS queries. More moving parts, but the right shape when several reports share the same extracted data — you pay the extraction cost once.
3. Direct SQL against the Acumatica database. Do not. On SaaS you have no access anyway; on private cloud the schema's CompanyID discrimination and DeletedDatabaseRecord soft-delete flags mean naive queries return wrong numbers, and every upgrade is a breaking change you find out about in production. If someone insists, insist back on a read replica and a documented view layer — and even then, prefer option 1.

GET /odata/KG-SalesMargin?$filter=OrderDate ge 2026-06-01&$top=500 HTTP/1.1
Host: yourinstance.acumatica.com
Authorization: Basic {base64 user:password}
Accept: application/json

What SSRS genuinely does better

• Subscriptions and bursting. SSRS subscriptions — render this pack every Monday, one PDF per region, email each to its manager — are mature and self-service. Acumatica's Automation Schedules can email a report, but data-driven bursting takes custom work.
• Layout horsepower. The tablix is simply a stronger layout engine than the .rpx band model for matrix-style analytical layouts with dynamic column groups.
• Cross-system joins. An SSRS report over a reporting database can blend Acumatica, your WMS, and your e-commerce data. The embedded designer only ever sees DACs.
• Existing skills and estate. Fifty tested SSRS reports and a fluent developer are real assets. Repointing data sources is cheaper than rewriting layouts.

What you give up outside the platform

Everything I listed for documents, plus the quieter costs: SSRS runs under a service credential, so Acumatica's row-level security, branch restrictions, and restriction groups do not apply — you rebuild audience scoping in SSRS's own security model. Reports live outside your customization project, so they version and deploy on a separate track. And you now run a Report Server (or Power BI Report Server) — patching, backups, one more thing on the DR checklist.

The split that works in practice

The arrangement I set up for a distribution client running both, and would set up again:

• All documents in embedded Report Designer, packaged in the customization project. No exceptions — this is the hill I die on.
• All operational in-app reporting (registers, edit reports, aged AR/AP) also embedded, because users run them from the screens they already live in.
• Scheduled analytical packs and cross-system reports in SSRS, fed exclusively by named GIs over OData — one GI per report, so the data contract is explicit and versionable.
• One integration user for SSRS, with access scoped to those GIs and nothing else, so a leaked credential exposes report feeds, not the ERP.

Wrapping up

SSRS versus the embedded designer is not a technology beauty contest — it is a question of which side of the document/analytics line the report sits on. Documents belong in the platform, always. Analytics can defensibly live in SSRS when you already own the estate, provided the data flows through GIs and OData rather than raw SQL. And if you are starting from zero on analytics, skip the question entirely and evaluate Power BI first.