Finance & AccountingFree
General Ledger Export to Trial Balance
Whatever QuickBooks, Xero or NetSuite exported becomes one trial balance on your reporting chart, footing to the same total, with every mapping assumption named.
River's trial balance normalizer reads a QuickBooks, Xero or NetSuite export and returns a trial balance mapped to the reporting chart you actually use. Every line carries the account it came from, the reporting code it landed on, and the rule that put it there. Alongside it comes a document recording the mapping decisions, the accounts that could not be mapped, and the accounts that were never in the file. The debit and credit totals are footed before and after the mapping.
Two ranked competitors already auto-map a QuickBooks trial balance, so reading the file is not what is missing. Both map onto a fixed chart and settle ambiguity by guessing into a catch-all. This one maps onto your chart and proves the result is a relabelling: the same 242,350.00 foots before and after. Where a single account has to reach three reporting codes, the basis for that split is not in a trial balance. It is recorded as an assumption, not derived.
Written for controllers and fractional CFOs facing a different chart of accounts on every client. It also fits anyone whose trial balance came back out of balance against the ledger behind it. Normalizing is one task on a wider close, tracked on the month end close checklist. The transactions behind it often start as bank statement PDFs, and an ecommerce client's deposits need settlement reconciliation first. A fund CFO works this way across a portfolio, and the footed balances are what a cash flow forecast or a projection narrative has to start from.
Balancing is necessary, and it is not sufficient
A trial balance that foots has passed one check, and OpenStax's accounting text is blunt about the limits: errors survive a balanced trial balance. In the worked example above the naive pivot came back 6,500.00 apart. That difference is the visible residue of 13,500.00 of misplacement, because an amount in the wrong column is wrong twice, absent from one side and present on the other. A reader sees 48.1% of what is actually there, and no amount of staring at the difference reveals the rest.
The column cannot be read off the account's class, and that is the failure the example isolates. QuickBooks publishes five classifications, Asset, Equity, Expense, Liability and Revenue, and none of them tells you which way a given month moved. Deferred Revenue is a liability whose March net change is a 5,000.00 debit. Filing it under Credit because liabilities are credits introduces 10,000.00 of error. Read the same pivot from each line's sign instead and it foots exactly, at 35,650.00.
Mapping needs a second request, which is why this is not one export. The Trial Balance report returns three columns, Account, Debit and Credit, and each account cell carries an internal id and a display name, so classification has to be fetched separately. Sub-accounts are worse than fiddly. Intuit records that its own General Ledger report hierarchy is broken when sub-accounts exist, and rolling two children into their parent here moves 22,400.00 onto the wrong reporting code.
How it works
Add the export
Paste the general ledger or trial balance export from QuickBooks, Xero or NetSuite.
Give it your chart
Paste the reporting chart of accounts you map every client onto, in any format.
River foots and maps
Each line's column derived from its sign, then the totals checked before and after mapping.
Work the exceptions
Resolve the unmapped accounts, confirm any split, then add the next client and rerun.
What you get
- One trial balance on your reporting chart, footed on both sides before and after mapping
- Every line shows the source account, the code it landed on, and the rule applied
- The column derived from each line's sign, never guessed from the account's classification
- Accounts that could not be mapped listed individually, rather than swept into a catch-all
- Accounts with a balance but no activity kept, since a pivot on activity drops them
- One-to-many splits recorded as assumptions, with the second input they needed named
Common questions
My trial balance does not match the general ledger. What is wrong?
Usually the column rule, not the arithmetic. A ledger export gives one signed amount per line, so something has to decide which side each account lands on. Deriving that from the account's class rather than the line's sign puts contra assets, and any liability with a debit month, on the wrong side. In the example above that single rule accounts for the whole 6,500.00.
What is a reporting chart of accounts, and do I need one?
It is the fixed chart you present on, rather than the one the client keeps books in. They are real and sometimes mandatory. Canada's revenue agency publishes the GIFI, where every financial statement item has a unique code and cash is 1001. If you already map every client onto one internal chart, paste that instead. GIFI is a worked example here, not a US filing requirement.
Does the row count stay the same?
No, and it changes in both directions at once. In the worked example 17 client accounts become 18 reporting lines: two revenue accounts collapse into one code at 30,500.00, and one accumulated depreciation balance has to reach three codes. Both sides still foot at 242,350.00, which is the check that matters. Counting rows is not one.
What happens when one account has to split across several codes?
It gets flagged rather than allocated silently. Splitting accumulated depreciation across asset classes needs the gross asset balances by category, the fixed asset register is where those come from, not a trial balance. Given them, the split is computed and shown. Withheld, the account is listed unsplit with the missing input named. A pro-rata number invented from the trial balance alone is an assumption dressed as a derivation.
Will it work on a Xero or NetSuite export instead?
Yes, and they are genuinely different shapes. Xero returns five columns and glues the account code inside the name string, so Sales (200) has to be split back apart. NetSuite uses positive notation for debit accounts and negative for credit ones, with no column pair at all. Each is read on its own terms rather than through one column mapper.
What about accounts that are missing from the file entirely?
They come back as a third bucket, separate from unmapped. A trial balance lists only accounts with a nonzero balance, so a dormant account is legitimately absent and was never unmappable. The dangerous case is different: an account with a balance and no activity in the period, which any pivot on activity drops. That was 150,000.00 in the example.
Is the output audit-ready?
No. It is a working paper, and the mapping decisions in it are yours to approve. Two reports that disagree stay a judgement call, and conflicting report reconciliation is the tool for that. Use this to get one defensible trial balance on your chart. Evidencing those balances outside the ledger is the balance sheet substantiation pack.
General Ledger Export to Trial Balance
Fill in the form and your workspace opens with the work already underway.