Connecting and Reconciling Across NetSuite, Sage, SAP and Oracle

A controller at a company running three entities once described her close to us as “waiting.” One subsidiary on NetSuite, one on SAP, one still limping along on a Sage instance nobody wanted to migrate. Every month she emailed three people, waited for three trial-balance exports, opened three spreadsheets in slightly different layouts, and started mapping accounts by hand. The actual consolidation took an afternoon. The waiting took eight days.

That gap is the real cost of multi-ERP finance, and it’s where most “close automation” tools quietly give up. They connect to one system cleanly, read from the others through a nightly CSV drop, and call the result integration. It isn’t. It’s a faster way to assemble the same fragile pile of exports.

Exports are not connections

A CSV export is a photograph of the ledger at one moment, taken in a format the source system chose for accounting, not for matching. SAP, Oracle, NetSuite, and Sage each store accounts payable, receivable, and the general ledger in structures optimized for their own posting logic. Pulling usable transaction data out of them means a transformation step every single time, and transformation pipelines built on exports are where reconciliation quietly breaks.

The failure modes are boring and expensive. A posting period closes in one system before the export runs, so the trial balance you consolidated is already stale. A subsidiary books an intercompany entry that the parent’s export hasn’t picked up yet, and the two sides don’t tie. Someone renames an account in Sage, the column mapping silently shifts, and a number lands in the wrong line of the consolidated P&L. None of these throw an error. They just produce a model that looks finished and is wrong.

Read-only export feeds also can’t do the one thing that actually closes the loop: write a correction back to the source. When reconciliation surfaces a difference, you fix it in the export, not in the ledger. Now your model and your GL disagree, and the next export overwrites your fix.

What a real connector does

Native connectors talk to each ERP through its own write-capable interface, not a flat-file dump. NetSuite is the instructive case because it exposes several: SuiteTalk for enterprise-grade integration, RESTlets for custom endpoints, and SuiteQL for querying journal data with something close to SQL. Through SuiteQL you can pull journal entries by posting period and date range and read the TransactionAccountingLine table to see exactly which accounts a journal hit and the debit and credit on each: the GL impact, line by line, not a summarized total. That granularity is the difference between “the balance moved” and “here is the entry that moved it.”

The same principle holds across the others. Oracle and SAP expose API surfaces that return posted entries with their account dimensions intact. Sage has its own. The connector’s job is to read at that level of detail and, critically, to write back at the same level: a properly formed journal entry with the right accounts, periods, and subsidiary dimensions, posted through the system’s own API so the ledger stays authoritative.

Bi-directional sync is the part people underestimate. Reading is easy. Writing back accurately is hard, because an incorrect writeback is worse than no writeback: it corrupts the source of truth everyone downstream trusts. So a writeback has to respect each system’s validation: NetSuite’s subsidiary and period locks, the local chart of accounts, intercompany elimination rules. Done right, when you resolve a difference in the model, the correcting entry lands in the actual GL, and the next sync confirms the two now agree.

One model, mapped once

The harder problem isn’t connection. It’s that each legal entity often runs a different chart of accounts. NetSuite OneWorld handles this internally by letting subsidiaries keep local accounts that map up to a corporate structure during consolidation. But the moment one entity lives in SAP and another in Sage, that built-in mapping stops at the NetSuite boundary, and you’re back to aligning charts by hand.

The fix is to map once, into a single normalized model, and keep the mapping as durable infrastructure rather than a spreadsheet someone rebuilds each quarter. Rexfin connects to each ERP natively, reads at the journal-line level, and resolves every entity into one reconciled financial model: a single source of truth that ties out to each underlying ledger. Account 6100 in the Sage entity and its SAP equivalent both land on the same consolidated line because the mapping is explicit and versioned, not inferred from a column header. Intercompany activity, which is the most common source of reconciliation errors in multi-entity accounting, gets matched across systems instead of within each one.

We’ll concede the limit plainly: native connectors are more work to build and maintain than a CSV importer, and the first mapping pass for a messy multi-entity setup takes real effort. There’s no version of this that’s instant. What you get for that effort is a model that stays reconciled between closes instead of being reassembled at each one, which is the whole premise of a continuous close rather than a monthly crunch.

Why this matters for AI

Here’s the part that’s easy to skip. If you want AI to answer questions about your numbers (consolidated margin by entity, intercompany exposure, a what-if on a currency move), it has to read from something trustworthy. Point a model at three exports and it will confidently average inconsistencies. Point it at one reconciled model that ties to every ledger, and its answers trace back to a real journal entry you can open.

That’s the architecture Rexfin is built on. The reconciled model is the substrate; the AI retrieves figures from it and runs the math through a deterministic engine rather than the language model, so a reconciliation difference is something you can audit, not a number the model invented. The same discipline applies to how entries get matched in the first place: traceable matching, not untraceable automation.

The takeaway is narrow and worth holding onto: if your finance AI reads from exports, it inherits every gap between those exports and the ledger, and it will hide them better than a spreadsheet ever did. Native connectors with accurate GL writeback aren’t a nice-to-have on top of close automation. They’re the foundation that makes the rest honest.

If you run more than one ERP and your close still starts with waiting for exports, book a demo and bring your messiest entity. That’s the one worth seeing reconciled.