Design Backwards From the General Ledger

Most systems architecture runs forward. Pipeline first. Then quoting. Then fulfillment, then billing. The general ledger gets whatever falls out the end.

Then it’s quarter-end, and the GL tells a different story than the operational systems do.

I’ve watched leadership teams debate pipeline data while the financials quietly disagree. The CRM says one thing. The books say another. Guess which one the board believes.

That’s it. That’s the method.

Why forward design fails, and always at the same moment

You can have the most sophisticated CRM in the world, with robust opportunity tracking and dashboards that look terrific in a board deck. But if that data doesn’t flow cleanly into the ERP and produce accurate GL impacts, you’re running two versions of the truth.

Only one of them matters come quarter-end.

Plenty of upstream processes never touch the ERP directly. Sales happens in the CRM. Fulfillment happens in a homegrown system. Procurement happens in some specialty tool. That’s fine — the best-of-breed argument is a real one, and I don’t fight it.

It stops being fine when those systems fail to feed billing, cash collections, and ultimately the revenue line of the income statement.

The failure is never announced. It shows up as reconciliation. If your operations team and your finance team spend the last week of every month explaining the difference between two numbers, you don’t have a discipline problem. You have an architecture problem.

The chart of accounts is the DNA of the system

Your chart of accounts isn’t a list of numbers. It’s the structure every report you will ever run has to live inside.

And for most growing companies, it was designed for a company that no longer exists.

The business expands. New geographies, new SKUs, new business models, a new entity for a new market. The CoA stays frozen in time. Nobody makes a decision to leave it alone; it just never becomes anyone’s Tuesday.

What that looks like in practice, over and over:

• No segment strategy — no deliberate decision about what gets tracked as an account versus what gets carried as a dimension on the transaction. (A segment or dimension is a field that slices a transaction — department, class, location, project, product line — without multiplying your account list.)
• Departments hard-coded into account numbers instead of dimensioned, so adding a department means adding twenty accounts.
• The GL overloaded with vague catch-all accounts that absorb anything nobody wanted to think about.
• One-off workarounds that became permanent.

Eventually the company can’t answer questions a CFO should be able to answer in an afternoon. What’s our margin by product line? How much are we really spending on sales operations across regions?

If your GL looks like a junk drawer, you’re not alone. Everything’s in there. Nothing’s findable.

The fix isn’t cosmetic. Restructuring a chart of accounts is a design exercise about what the business needs to see — and it has to happen before the upstream systems are configured, because the upstream systems are what populate the dimensions. A segment nobody stamps on the sales order at the moment of sale is a segment your controller will be reconstructing by hand at close. Forever.

What is a top-side entry, and how does one become a shadow set of books?

A top-side entry is a manual adjustment made above the ledger — booked outside the system, usually in a spreadsheet, after the ERP has produced its numbers, to make the reported financials come out right.

No shame. We get it. It starts with one adjustment.

Then a few more.

Before long there’s a shadow version of your books living in a spreadsheet.

And then it breaks.

The numbers in the system no longer match what’s reported. Audits get messy, fast, because the adjustment has no traceable logic and no audit trail back to a source transaction. Someone fat-fingers a formula and the financials are simply wrong. And leadership can’t use real-time system data to make decisions, because everyone quietly knows the system data isn’t the real number.

I’ve lost count of how many times I’ve seen this. In multi-entity companies it’s worse, because the top-side entries aren’t just adjustments — they’re generating the statutory books, the local-entity financials filed with each country’s authorities. Extracts get emailed to a third-party firm for the local tax filing. The elimination entries get booked by hand. Transactions get recorded in the reporting currency instead of the currency they actually occurred in, because someone decided at implementation that the system couldn’t handle it.

Be honest about what that means. If your financial statements can’t be pulled straight out of your ERP, your truth doesn’t live in your system. It lives in a spreadsheet.

The consolidation failure I see most often

Here’s the one that still surprises me, and it’s the most common problem I encounter when I talk to global companies.

They bought the multi-entity ERP. They implemented it. They went live. And they are still running their consolidated financials out of an Excel workbook.

Worse: they’re booking manual journal entries in the ERP to compensate for the workbook.

The cause is almost always the same. Intercompany accounting was set up wrong at implementation — the subsidiary structure didn’t match the actual legal and operating footprint, the intercompany accounts weren’t defined, elimination rules weren’t configured. (Eliminations remove transactions between your own entities so the consolidated statements don’t double-count revenue the group never earned from an outside customer.) So intercompany transactions post, but they don’t eliminate. The consolidated view doesn’t tie. And the team does the only thing it can: rebuilds the consolidation by hand, then reverse-engineers journal entries to make the system agree with the workbook.

Two systems of record, one of which is a file on someone’s laptop.

This is fixable. It takes time and effort, and we’re frequently brought in to do exactly that — to retroactively build the top-side adjustments into the system so it reflects actual business results. But it’s a rebuild, not a tune-up, and it’s the most avoidable rebuild in this business. Get the entity structure, intercompany accounts, currency treatment, and elimination logic right during implementation and the consolidated financials come out of the system. That’s the entire point of buying it.

A quieter version of the same problem

Not every case is global. A services company of roughly 250 people came to us with a labor cost allocation process that had lived in spreadsheets for five years — around 30,000 rows of time entries a month, mapped by hand to labor rates across multiple entities.

It worked. Sort of. It was also error-prone, slow, and invisible until the month was over.

The design question wasn’t “how do we make the spreadsheet faster.” It was: what has to hit the GL, at what level of detail, for management to see project profitability? Answer that, and the upstream requirement writes itself — time entries have to carry project, client, entity, and rate at the moment they’re recorded, and flow into the system as journal entries without a human in the middle.

They took a day out of the close. More importantly, they stopped being blind mid-month; they now pull the data weekly and can see how they’re tracking against budget before the month ends.

That’s what designing backwards buys you. Not just a faster close — earlier sight.

The questions to answer before anyone configures anything

Some people have compared my requirements-gathering to a Barbara Walters interview. I take that as a compliment. These are the questions, and they get answered before a single upstream workflow is built:

1. What financial statements must come out of this system, and for whom? Consolidated, per-entity statutory, board and investor reporting, lender covenants, tax. Name every consumer.
2. At what level of detail does each line need to be sliced? Entity, currency, department, location, product line, project, customer, contract. Then decide which of those are accounts and which are segments or dimensions. Getting this backwards is how charts of accounts become junk drawers.
3. Which of those slices must exist on the transaction when it’s created upstream? This is the whole ballgame. If Sales doesn’t capture product line at quote, Finance is guessing at close.
4. What is each subsidiary’s functional currency, what’s the reporting currency, and which transactions must be recorded in the currency they actually occurred in? Not the currency that was convenient for the old system.
5. How do intercompany transactions arise, and which ones must eliminate automatically? Include transfer pricing. If the answer is “the controller books them at close,” you’ve just designed next year’s Excel workbook.
6. What do local filings require, in each jurisdiction, and can the system produce them? If the plan is to hand extracts to an outside firm every quarter, say so out loud and price it.
7. What’s the close calendar? What has to post, by when, what’s the cutoff, and which upstream system has to be finished before Finance can start.
8. What will the auditor ask for, and can the system produce it with a trail back to source? Assume they will ask. They will.
9. Which manual adjustment are you making today, and what would have to be captured upstream to make it unnecessary? Every recurring top-side entry is a specification for an upstream requirement someone skipped.
10. What changes in twenty-four months? New entity, new country, new revenue model. Does the structure absorb it, or does absorbing it mean another implementation?

Answer those ten, and the upstream design stops being a matter of opinion. Quoting, billing, fulfillment, and procurement all have a job description now: deliver these fields, on these transactions, by this date.

The ruling

Finance isn’t downstream. Finance is the specification.

Design forward and you’ll spend every quarter-end reconciling two systems that were never asked to agree. Design backwards from the general ledger and the reconciliation disappears, because there was only ever one version of the truth to begin with.

Decide what has to hit the GL. Then build toward it.

Fix the plumbing, and the rest follows.