The ledger, at line level
Chart of accounts, journals, all subledgers, and every dimension your system does hold — extracted at transaction line level rather than as summary balances, because summaries cannot be re-dimensioned later.
Services · integration
The most common reason a company starts shopping for a new ERP is that their accounting system cannot produce P&L by department, location, or project. That is a dimensional data problem, not a ledger problem, and replacing a working ledger to solve it is the most expensive available answer.
Tell us your accounting system and what reporting you cannot get. We will scope it and price it.
The situation
Read-only extraction, mapped into a graph that reconciles to your trial balance every night. Your accounting system keeps doing what it does.
Chart of accounts, journals, all subledgers, and every dimension your system does hold — extracted at transaction line level rather than as summary balances, because summaries cannot be re-dimensioned later.
Department, location, entity, project, and service line derived from the transaction and its relationships, so a P&L cut your ledger cannot produce becomes a query.
The graph reconciles to your trial balance nightly. A divergence raises an alert with the transactions attached rather than being discovered at close.
Two to five years back-loaded, which is what makes period comparison possible on day one rather than in a year.
Customers and vendors matched against the CRM, billing, and spend systems, so the same company is one object rather than four near-duplicates.
Every engagement starts read-only. Write-back is a separate, later decision made once the reconciliation has been clean for a period.
QuickBooks has classes and locations. Xero has tracking categories, two of them. Both are single-dimensional, both were designed for a simpler business than the one you now run, and neither can express “this transaction belongs to this project, for this client, in this office, delivered by this team.”
So the reporting gets built in a spreadsheet, monthly, by somebody senior, from an export. That spreadsheet is the actual management reporting system in a surprising number of companies between $10M and $100M, and it is the thing an ERP purchase is usually trying to eliminate.
Any competent engineer can pull data out of QuickBooks. What makes the result trustworthy is the daily reconciliation: total debits, total credits, balance per account, and transaction counts compared between source and graph, every night, with mismatches raised.
Without it, you have a second copy of your financial data that nobody can vouch for, and within a quarter somebody will find a discrepancy and stop trusting the whole thing. The reconciliation is what turns an extract into a source you can report from.
Once the graph is running and reconciling, three things become low-risk that were not before. Agents have enough context to be useful. Reporting stops being a spreadsheet. And if you do eventually decide to move the ledger, the migration is a cutover against a dataset that has already been proven to match — rather than a leap.
That last point is why we recommend this as the first engagement even for companies who are fairly sure they want a new system. It is the cheapest way to find out whether they do.
Where to start
We connect read-only, extract a sample, and report on data quality — duplicates, missing dimensions, unbalanced periods. You get the findings whether or not you proceed.
Chart of accounts mapped, dimensions derived, master records matched. This is the part where your controller earns their keep and where the decisions get made.
History loaded, nightly tie-out running, discrepancies chased until the reconciliation is clean for a full period rather than for a day.
The reports you could not get before, built and scheduled. Then a written summary of what was mapped, what was assumed, and what remains imperfect.
Questions
Tell us your ledger and what you cannot report on. We will scope it in a week.