A configuration can demo perfectly and still be wrong. We have watched a system sail through user acceptance — every screen correct, every approval routing where it should, sign-off all around — and then, at the first month-end, the subledger misses the general ledger by a few thousand dollars. The gap is small enough to wave off in week one. By quarter-close it is a reconciliation project with its own status meeting.
The screens were never the problem. The problem is that the build modeled the business process and assumed the accounting would follow. It does not follow. An ERP is not a forms-and-workflow application that happens to keep books. Underneath the modules and the menus, it understands exactly one thing, and it is ruthless about it: a posting that balances. Debits equal credits, against real accounts, at a moment in time. Everything else — the order, the receipt, the approval, the beautifully laid-out screen — is theater the system tolerates on the way to that single fact.
So we stopped designing forward from the process and started designing backward from the posting.
Why the screen lies and the ledger doesn't
A transaction screen can be fully configured and still produce nothing the ledger will accept, because the screen and the posting are two different layers. The screen captures intent. The posting commits consequence. Between them sits the accounting logic — the account determination, the document type, the posting period, the tax and currency handling — and that logic is where a build is actually right or wrong. You can get every field on the screen correct and still have an event that posts to the wrong account, in the wrong period, or not at all.
This is why a demo proves so little. A demo exercises the screen. The close exercises the posting. The two come apart at exactly the seam most projects never test, because testing it means tracing a transaction past the confirmation message all the way to the trial balance and asking whether it ties.
What the ledger actually asks of every transaction
Before a build is done, every transaction type has to answer the same short list of questions. Not the business questions — the ledger's questions. These are the ones the system is silently asking whether or not anyone configured an answer:
- Does it balance? Every event must resolve to debits equal to credits. If the design can produce a one-sided posting, the design is unfinished, not flexible.
- Which accounts, and decided by what rule? Account determination should be a stated rule, not an operator's choice. The same event must land in the same place every time, or reporting inherits the variance.
- In which period does it land? Posting date is an accounting decision, not a timestamp. A transaction that slips a period turns a clean close into a manual adjustment.
- What reverses it? Every posting needs a defined way back. If the only way to undo it is a hand-typed journal, you have built a leak.
- Can it be traced end to end? From source event to trial-balance line and back. If a number cannot be walked back to the thing that caused it, it will not survive audit.
None of these is exotic. What is uncommon is asking them at design time, of every transaction, before the screen is built — rather than discovering the unanswered ones at close, one painful variance at a time.
The discipline is designing backward
We design from the posting outward. First we decide what the balanced entry has to be — which accounts, which period, which reversal. Then we work back through the accounting logic that must produce it, and only last do we lay out the screen that feeds it. Built this way, the screen cannot capture an intent the ledger can't honor, because the ledger's requirements were the starting constraint, not an afterthought.
It is slower at the front and far cheaper at the back. The build that models the process first looks faster for a month and then spends the next two quarters reconciling. The build that starts at the posting is quieter: transactions hit the accounts they were designed to hit, the subledger ties to the GL because it was never free not to, and the close is boring. This is also why an integration has to be safe to rerun and why the dollars are calculated, never guessed — both are the same instinct applied one layer out: protect the posting.
It ties back to the ledger
An ERP is generous about almost everything and unforgiving about one thing. It will let you configure the workflow you want, name the screens what you like, route approvals however suits the org. It will not let an unbalanced posting stand, and it will not pretend a number ties when it doesn't. Configure with that order of priorities — balance first, screen last — and the system does what it was built to do. Invert the order, and you spend the year teaching it to forgive a design that never spoke its language.
The dialects differ across SAP, Oracle, NetSuite, Workday. What they understand underneath is the same sentence, and it is always the one that balances.