Sage — Three Products, Three Data Stories

Sage runs the books of a large share of British and Irish business, and it has earned that position over four decades. Keeping three separate product lines current against a moving compliance target is a substantial ongoing commitment, and Sage has met it. The question is not whether Sage is a good system. It is that “we run Sage” tells a reporting team almost nothing until you know which Sage.

At a glance

What Sage is

Sage is a British software company that sells finance software at three distinct sizes, under one brand, on three unrelated codebases. Sage 50 Accounts, Sage 200 and Sage Intacct are not editions of one product; they are separate products with separate release cycles, developer portals and database architectures.

Market compounds the confusion. In the UK and Ireland, “Sage 50” means Sage 50 Accounts, a desktop product. In the United States it means Sage 50 Accounting — formerly Peachtree, on a different data engine, and since 2025 split into Sage 50 Cloud and Sage 50 Desktop. The names collide; the products do not overlap. This article describes the UK and Irish products throughout.

Sage Intacct arrived differently, built as a multi-entity cloud general ledger by an independent company and acquired by Sage in 2017. It is the only line designed after the question “how will people report on this?” had a modern answer.

The three product lines

Everything a reporting team needs to know is in one table. This is why Sage gets one article rather than three.

Read down the “primary read route” row and the consequence is obvious. Each line needs a different connector, a different credential model and a different extraction schedule — and any reporting layer that claims to “connect to Sage” without asking which one is not being straight with you.

Two details deserve naming, because they are where projects go wrong. First, Sage 50 Accounts has never been a SQL product and is not one now — Sage’s own support pages document the ACCDATA folder, the .DTA files and the data service. Second, Sage 200’s data is split across databases rather than partitioned inside one, in Sage’s own words: “as many company databases as they need, they are all separate and not shared.” Cross-company reporting in Sage 200 is therefore a cross-database problem, which is why the in-product consolidation posts a journal rather than running a query.

Who Sage fits

Small British and Irish companies with a bookkeeper in the building. Sage 50 Accounts is Sage’s own answer here, and a good one: a desktop install that does not depend on connectivity, VAT and Making Tax Digital handled, a Report Designer anyone can be trained on, and a support ecosystem with no equal in the UK small-business market.

Mid-market UK and Irish businesses running stock, orders and projects. Sage 200 sits precisely where a growing distributor, manufacturer or contractor needs it: real stock control and order processing, project accounting, a mature partner channel, and SQL Server underneath so a competent partner can build what the base product does not.

Multi-entity groups and finance teams who report for a living. Sage Intacct’s home ground: native entities under one top level, dimensional accounting, consolidation with currency translation, and an actively developed REST API.

Companies Sage is inviting up a tier. Intacct is where Sage steers its own smaller customers, publishing migration paths from both Sage 50 and Sage 200; Sage’s word for the move is “graduating”. Make that decision on operational grounds; the reporting layer lets you validate the new system against the old while you do.

Groups that grew sideways. A UK parent on Sage 200, an Irish subsidiary on Sage 50 Accounts, a Slovak trading company on POHODA. Every one of those choices was locally correct — and because Sage has no product at all in central Europe, this shape is the norm in a CEE-centred group.

What Sage holds — and why it is good material

Before the reporting question, the asset. All three lines hold well-formed, reconciled double-entry data, and the data quality in a properly run Sage installation is usually good — a stronger starting point than the spreadsheet consolidations and half-configured cloud tools we more often meet.

Sage Intacct’s dimensions are worth genuine credit, precisely stated. Most accounting systems ask you to encode analysis into the account code. Intacct declined to do that. Its chart of accounts is deliberately flat and short; the analysis lives in dimensions recorded alongside the account. Fourteen dimensions ship as standard — among them Location, Department, Project, Customer and Item, several switched on by the module that needs them — and user-defined dimensions extend the set, with parent-child hierarchies throughout. That was the right architectural call, made before most of the market got there, and it means an Intacct ledger arrives already shaped for profitability analysis .

Sage 200 holds the richest transactional detail of the three, in SQL Server. Nominal codes carry cost centre and department segments, stock and order processing reach line level, and Project Accounting adds costing structure. Sage 50 Accounts holds less, and holds it cleanly — nominal ledger, customers, suppliers, stock, bank, VAT, with departments and, in Professional, project costing. Its file format is stable across versions, and Sage ships its own ODBC driver specifically so the data can be read outside the product — a vendor deliberately opening a small product’s data.

What sits outside Sage’s scope

Each line is scoped to a job and does it. Three things sit outside all three scopes, each a boundary drawn deliberately.

The view across companies, at transaction level. Sage 50 Accounts has no cross-company mechanism at all, by design — one company, one folder. Sage 200 Professional consolidates by posting a journal into a nominated parent company, which gives a correct parent-company set of figures periodically rather than a live group view you can drill. Sage Intacct goes considerably further and deserves the credit; its own documented boundary is that Global Consolidations assumes a flat entity structure with each entity wholly owned — a reasonable line for statutory consolidation , and a real boundary where the ownership chart is not flat.

The view across systems. Whether e-commerce revenue matches the ledger, whether the stock system agrees with the balance sheet, whether the payroll run matches headcount in the HR system. This is worth saying plainly: no ERP does this. Not Sage, not Business Central, not SAP. Cross-system truth is a layer above every transaction system, which is the point we make at more length here .

The management view, held somewhere durable and shared. Each line’s reporting tools are capable within their scope, and each runs out in the same place. Sage Intacct has the sharpest example, documented by Sage itself: its own dimension groups explicitly do not work outside General Ledger reporting. Sage 200’s Business Intelligence module is similarly bounded. Each is the ordinary consequence of a reporting tool living inside a transaction system, and each means the data model a dashboard or an AI assistant queries across a group has to live elsewhere.

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

We connect all three Sage lines, singly and in combination, and alongside whatever else the group runs. Getting the data out is a different job in each line, and being precise about which is most of the work.

On Sage 50 Accounts we read through Sage’s own ODBC driver — authentication as a real Sage user, read-only by design: in Sage’s words, you “cannot update information back into Sage Accounts”. We schedule around the licensed-user constraint and take a full extract — the safer choice at this tier’s volumes.

On Sage 200 our default is a read-only SQL login per company database, which Sage documents, with the REST API where a partner does not grant database access. Sage’s position is worth respecting: reading is documented, and “direct changes to the database including triggers are not supported”. We never write.

On Sage Intacct there is no database to read, and that is correct for a multitenant service. We use the REST API, generally available since 2025 Release 1, with the XML gateway where an object has not moved yet — incremental extraction, queries kept inside the documented page and timeout limits, and Sage’s Performance Tier entitlements planned for rather than discovered. Where volumes justify it, Sage’s own Data Delivery Service or Data Cloud for Snowflake replaces the API as the bulk route; Data Delivery Service publishes current state rather than history, so historisation is ours to build.

What happens next is the Sage-specific work.

The Intacct dimension model, carried through rather than flattened away

The commonest thing done to a dimensional ledger on the way into a reporting tool is to flatten it and lose most of it. We do the opposite. Every standard and user-defined dimension arrives in the model as a first-class attribute, hierarchies intact, with parent values preserved so a deactivated child still rolls up. Then we rebuild the dimension groups you have already defined in Intacct — the groupings that cannot be used outside General Ledger reporting — as reusable objects in the governed layer, available to every dashboard , export and AI query.

A management chart of accounts across a flat Intacct ledger and a Sage nominal one

Intacct’s chart of accounts is short and flat by design; Sage 50 and Sage 200 use a nominal structure with cost centre and department segments. The statutory chart in each entity keeps doing its job. Above it we build a second structure designed to answer management questions — revenue by what you actually sell, cost by what you actually control, gross margin at the level you actually decide — mapped once, versioned, owned by a named person, reviewed at each close. More on the design problem underneath: chart of accounts architecture .

One view across folders, databases, entities and systems

Each Sage 50 data folder, each Sage 200 company database and each Intacct entity becomes one entity in a common model — beside a POHODA database, a Business Central environment, a Xero organisation or an e-commerce platform. Group reporting in any currency with currency translation applied consistently, reconciliation across systems, and drill-down from a consolidated total back past a Sage 200 consolidation journal to the subsidiary entry behind it. This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

• Which customers are actually profitable, after delivery, discount and service cost?
• What is group EBITDA in one currency, when the parent is on Sage 200, a subsidiary is on Sage 50 and the newest entity is on Intacct?
• Why did overhead move this month, ranked by the cost lines that moved most, against budget and last year?
• Which entities have dimension or department gaps, and on which accounts, before the close rather than after it?
• What does cash flow look like at group level, weekly?

Every one of these is answered from data Sage is already holding. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity Sage client, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only access, and a conversation about what the numbers should mean.

What does not change: Sage stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

JING Tea — Sage 200 as the starting system, and the layer that outlived it

JING Tea is a premium single-garden tea brand founded in London in 2004, selling through direct e-commerce, wholesale and international retail. We have run their management reporting for three-plus years. From day one the layer unified several disconnected sources — Sage 200 accounting and inventory, manual inventory feeds and hand-built budgets — into one consolidated view, with a standardised chart of accounts, SKU master, customer hierarchies and channel taxonomy, and automated daily extraction.

Then the stack changed. Last year JING replaced its entire operating estate: Sage 200 out, Shopify, Xero and CIN7 in. The reporting moved between the two systems with the transaction-level Sage history kept in the layer. The same layer absorbed it. Old and new ran in parallel through cutover, no history was migrated, and the Sage-era history and the new-stack performance sit side by side in one model — same chart of accounts, same channels, same drill-down from P&L to the individual sales order. Claude AI is now connected on top, and the team asks questions in plain English against numbers that already reconcile.

When Sage is eventually replaced

Sage is often the departure point rather than the destination. Some companies take Sage’s own route up to Intacct; others move outward to a Business Central, a NetSuite or, at the smaller end, a Xero.

In every one of those directions the same thing holds: because the governed layer sits above the ERP, only the connection changes. The data model , the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first find the migration measurably easier, because they can prove the new system’s numbers against the old system’s from day one — and they keep their reporting history rather than starting again. That turns a migration from an act of faith into a reconciliation.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.

How it compares

Sage’s absence from central Europe is itself the useful fact. Sage has no localised finance product for Slovakia or Czechia, and its Polish locale resolves to a Sage X3 site. So when Sage appears in a CEE-centred group it is almost always a UK or Irish entity, sitting beside systems chosen locally and correctly.

From a data-layer perspective the choice matters less than it appears. Each of these becomes an entity in the same governed model, which means the ERP decision can be made on operational fit rather than on reporting fear. The full matrix — including the Polish stack — is on the series hub .

Frequently asked questions

Do we need to replace Sage to get proper management reporting? No, and we would usually advise against it. Keep Sage for what it does well — statutory correctness, VAT and Making Tax Digital, clean transaction capture — and build the reporting layer above it. Replacing a working ERP to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for Sage? No. Sage remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change ERP later, the reporting layer stays.

Is Sage an ERP or accounting software? It depends on the line. Sage 50 Accounts is accounting software — desktop accounting for small businesses, in Sage’s own words. Sage 200 is a mid-market ERP — stock, order processing and project accounting alongside the ledgers. Sage Intacct is cloud financial management, strongest in the general ledger and multi-entity structure rather than in operations.

What database does Sage use, and can we read it directly? Three lines, three different answers. Sage 50 Accounts (UK) uses no SQL database: each company is a set of .DTA files in an ACCDATA folder, read through Sage’s own read-only ODBC driver. Sage 200 runs on Microsoft SQL Server, one database per company — reading it is documented by Sage, writing to it is not supported. Sage Intacct is multitenant cloud with no customer-facing database, read through the API or Sage’s own export products.

Can Sage connect to Power BI? The route differs by line. Sage 200 has a first-party connector which “does not connect directly to your SQL database, but uses the Sage 200 API” — with documented limits worth knowing: base currency only, no brought-forward balances, archived transactions absent. Sage 50 is reached through its ODBC driver and Intacct through the API; neither has a first-party connector. Reporting straight off the transaction system means every user’s refresh lands on the live environment, and at Sage 50’s tier it also occupies a licensed user. Power BI on a governed model, refreshed once, reads faster and costs the operational system nothing.

Can Sage consolidate several companies? The honest answer separates the lines. Sage 50 Accounts does not, and never claimed to; Sage 200 Professional posts a consolidation journal into a parent company — periodic figures, not a live group view. Sage Intacct genuinely does consolidate natively — the strongest in this series at it — within a flat, wholly owned entity structure. A group that spans product lines, systems or tiered ownership is the most common reason multi-entity Sage users come to us.

Does Sage have an API? Two of the three lines do, and both are real. The Sage 200 API is REST over OAuth 2.0 via Sage ID; one constraint shapes serious use — machine-to-machine authentication is not permitted, because Sage requires the initial authentication to be performed by a person. The Sage Intacct API is the more capable surface — a REST API generally available since 2025 Release 1, alongside the long-standing XML web services gateway. Sage 50 Accounts has no public API; its supported read route is the ODBC driver Sage ships for the purpose.

Is Sage’s own reporting enough? For a single company, often yes — and worth using before adding anything. Each line’s stack — Report Designer on Sage 50, Excel Reporting on Sage 200, Intacct’s report writers and Interactive Visual Explorer — runs out in the same place: across companies, across product lines, across systems, and anywhere a definition needs to be governed rather than rebuilt per report. More on where the line falls: business intelligence and reporting .

Official Sage resources

• Sage 50 Accounts — Sage UK
• Sage 200 — Sage UK
• Sage Intacct — Sage UK
• Sage 200 API documentation — developer.sage.com
• Sage Intacct web services — developer.intacct.com
• Sage Intacct dimensions — types of dimensions
• Sage Intacct consolidation options compared

Onetribe is not a Sage partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of ERPs — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your Sage estate — free assessment