The Bookkeepers Inheritance
Every ERP you’ve ever used was built for the accountant. The operator was an afterthought, the floor a remote province, the chart of accounts the only spine the system was ever given. The cost is operational distortion that no amount of configuration will close. What fixes it isn’t a better workflow engine; it’s inverting which events are first-class. The strange consequence, and the one that should change how the industry talks about this, is that putting the operator first leaves the executive better off than the bookkeeper-first version ever did.
Where ERP came from
ERP did not arrive as a category. It accreted, over twenty-odd years, out of two unrelated software disciplines that happened to share a customer.
In the late 1960s, factories with mainframes started running Material Requirements Planning: calculating, in batches, the parts and quantities a production schedule implied. MRP was a planning tool. It did not run the business; it told the materials manager what to order. By the late 1970s the same shops were running general ledger and accounts payable on the same machines. By the mid-1980s the vendors had realized the two systems shared masters and shared transactions and could be sold as one package. MRP II added shop-floor reporting; ERP added everything else. The category was complete by the early 1990s. SAP R/3 shipped in 1992. The architectural pattern was set, and most of what’s been shipped since is variation on it.
The pattern was rational for the conditions that produced it. Compute was scarce; batch was the only architecture that could perform cross-module aggregation at all. The customer at the table was the CFO, because the value proposition was clean books and the budget for the system lived under finance. The chart of accounts was the natural unifier: every module touched it, every transaction posted to it, every report rolled up through it. There was nothing else in the building strong enough to hold a multi-module system together, so the chart of accounts became the spine. Of course it did.
That was 1992. Compute is cheap, batch is one architecture among many, and the buyer is as often the CIO or the COO as the CFO. The chart of accounts is still the spine.
The bookkeeper’s inheritance is the architecture we kept past the point of its usefulness, because the vendors that ship it have no incentive to abandon it and the customers that buy it don’t know there’s an alternative.
What “accountant first” looks like in the schema
In an accountant-first ERP, every operational event has to become legible to the posting model. Journal entries, GL distributions, cost-accounting boundaries, inventory transaction types, and lifecycle states are the structural frame, and any operational reality the system can recognize has to fit inside it. The system models the business as journal entries waiting to happen. A purchase order moves through lifecycle states because those states correspond to recognizable accounting moments: requisitioned, approved, issued, received, vouchered, paid. A work order has lifecycle states because those states correspond to cost-accounting boundaries: released begins WIP, completed credits WIP and debits finished goods, closed posts variances. An inventory transaction has a transaction type because the type determines the GL distribution.
The operator’s job in this architecture is to type something the system can post. The system is asking: what financial event is this? The operator is supposed to answer in the system’s terms.
Operations don’t arrive in those terms. A work order does not exit the floor by transitioning cleanly from in process to complete. It is held for engineering review of an out-of-spec dimension. It is paused while procurement chases a long-lead substitute. It is split because half the kit arrived and half is on backorder and the line manager wants to start what they have. It is rerun against a different traveler after the first attempt damaged the fixture. It is set aside for a quality investigation that has its own clock independent of the production schedule. None of these is an accounting event. All of them are operational events. The system has language for the accounting events and no language for the rest.
So the operator picks the closest legal answer and types it in. The work order is in process, technically; the system needs a value, that value is true enough, work continues. The operational state, held for engineering review on dimension 3.4, lives somewhere else: on the supervisor’s whiteboard, in a planner’s spreadsheet, in a Slack thread between the line lead and the quality engineer, in someone’s head.
Nobody is lying. The system is faithfully recording what the operator typed. The operator is faithfully picking the closest legal value the system would accept. The lie, if there is one, lives in the gap between closest legal value and what the floor is actually doing; that gap is invisible to anyone reading the system rather than walking the floor.
Aggregate this across a thousand work orders, a hundred receipts a day, every cycle count, every transfer, every NCR, every CAPA, every nonconformance disposition, and you have a system whose dashboards are technically correct and operationally meaningless. The CFO gets clean numbers. The COO gets a picture of the business that bears only a polite relationship to the floor.
Why the patches don’t work
ERP vendors are not unaware of any of this. They have been responding to it for thirty years.
The responses are familiar: configurable workflow engines, status profiles, user statuses layered over system statuses, custom fields, low-code platforms, BPM tools, partner-built extensions. Every major vendor ships some version of the same offer: we know our standard model doesn’t fit your shop; here are the knobs you can turn to make it fit.
The knobs make the surface fit better and they make the underlying problem worse. Every new state, every custom field, every workflow branch has to terminate somewhere accountable to the books, because the chart of accounts is still what holds the system together. A status that doesn’t post is invisible to the executive; a custom field that doesn’t roll up is invisible to reporting; a branch that detours outside the standard lifecycle has to converge back into it before the work order can close. Configurations don’t add operational dimensions. They add filigree to the existing accounting spine, and the spine is still what’s being modeled.
Customer-specific configuration also erodes the canon. The customer hires consultants to build a workflow that captures the operation; the consultants build something that captures it on the day they finished; the operation evolves and the workflow doesn’t; the gap reopens wider than before, because the customer’s investment in the configured system makes them less willing to admit it isn’t working. Every deployment ends up a different system. The vendor’s documentation describes a product that does not, in production, exist anywhere. Audit logs from one customer mean different things from audit logs from another. Integrations against the configured surface are bespoke. The upgrade path is treacherous because the customizations have to be tested against every release. Drift accumulates because the configured surface becomes load-bearing: eight years in, the original consultants are gone, the planner who knew which custom fields mattered has moved on, and nobody can tell you why work orders at W3 post differently than work orders at W1.
The vendor’s response to the model doesn’t fit is we’ll sell you the means to make it fit. The customer does the work, pays for the work, and the work erodes the canon. Configurability is what the vendor has to sell, and using it is the customer’s only alternative to giving up on the system. So the system gets worse anyway.
This is the trap that makes the whole industry so frustrating to anyone who’s ever stood between the screen and the floor: closing the operational gap creates operational rigidity, because the only tools available for closing it are tools that bolt onto a spine that was never designed to carry the weight. The harder you try, the more rigid you get. The patches don’t converge on a faithful model of the operation; they converge on a Rube Goldberg approximation that imposes its complexity on every operator and every upgrade for the rest of the system’s life.
You can’t fix this by adding knobs. You have to move the spine.
The inversion
The move is to make operational events first-class and let the journal entries be derived.
A business is a state engine.
Something happens. The event creates a condition. The condition requires interpretation. Interpretation produces a decision. The decision authorizes an action. The action mutates operational state. The state change produces a result. The result is recorded as transactional data.
Event → Condition → Decision → Authorized Action → State Change → Result → Transactional Record → New Event/State
That sequence can branch, recurse, automate, delay, or cross organizational boundaries, but it does not meaningfully disappear. Even “no action” is still a state-preserving decision. Even automation is still a decision encoded as a rule. Even delayed batch posting is still the late representation of an earlier state change.
This is the physics of enterprise. Traditional ERP inherited the last visible artifact of that sequence, the transaction, and mistook it for the business.
In an operational-first system, the canonical record is what happened on the floor. A receipt records what arrived: quantity, lot, location, condition, who received it, what they noticed, what they staged, whether the count agreed with the packing list, whether the goods passed visual inspection, whether they’re held pending paperwork. The operator records the operation. The financial implications (the inventory increment, the AP accrual, the cost-layer entry, the tax accrual, the variance posting) are derived automatically, by rules that live in one place and are written by people who know what the numbers should mean.
That changes who is responsible for what. The operator describes reality. The system projects that reality into the financial frame, using rules the accountant maintains. Hand-typing journal entries to approximate operations the typist didn’t witness stops being anyone’s job, because there’s no scenario in the new architecture where it has to happen.
The shape of the schema changes too. State machines belong to operational entities; the ledger entries are downstream of those state machines. A work order has the states the floor needs (released, in process, held, awaiting engineering, awaiting material, in rework, in inspection, complete, closed, scrapped) because those are the states a work order goes through. Each operational state has a financial interpretation, defined once, declaratively, by accounting. Nobody on the floor has to know what held posts to. The accountant doesn’t have to imagine what in process covers; in process is one of nine operational states and they all have explicit GL projections.
The schema can adopt new operational states without renegotiating the ledger. When the shop invents split-build with pulled long-leads, the system models it; the accountant decides what it posts to; the financials follow. Configurability isn’t abolished; it’s been moved out of the customer’s lap and into the vendor’s, confined to the projection layer where its consequences are local and auditable. The customer doesn’t customize the spine. The vendor maintains a spine the customer never has to touch.
That’s what we mean by an operational engine instead of a historical ledger. The historical ledger is downstream. The operational engine is upstream. The architecture knows what’s happening on the floor in real time, in language the floor uses; it produces the books as a continuous, structurally correct side effect; the books reconcile to the operations because the operations are what generated them.
Whose system this is
There’s a deeper claim here that’s worth being blunt about: the operator is the system’s primary user, and the executive is a secondary beneficiary. This isn’t about who matters more. The operator is primary because the operator is where operational truth enters the system, and a system that doesn’t optimize for that point of entry is a system whose reporting is downstream of distortion.
The conventional view runs the other way and is rarely stated, because saying it out loud sounds bad. Enterprise software belongs to whoever signs for it. Executives sign the checks. The system gets built to serve their reporting needs. Operators are users in the diminished sense, labor inputs rather than stakeholders. “User-friendly” is a phrase that applies to the dashboards executives see, not to the data-entry screens operators use. The procurement decision is made on whether the executive will get the reports they want; the implementation decision is made on whether the operator will grudgingly accept whatever the consultants delivered. Whether the operator might quit if you deploy this particular system is a risk to manage, not a design constraint.
That’s upside down, and it falls apart the moment you ask who has the information. The executive doesn’t know what’s happening on the floor; the operator does, and the executive’s reporting is only as good as what the operator is willing to type. If the operator hates the system, what gets typed is the closest legal answer to a question the operator wished the system had asked. The executive’s dashboard is a faithful aggregate of those approximations. It’s wrong in the way that matters, and the executive can’t tell. There’s no error bar around closest legal answer, no flag for operator didn’t know what to put, no visibility into the gap between the screen and the floor.
Build the system around the executive and you guarantee the executive will be misled, not because anyone deceived them but because the people who hold operational truth have been treated as the system’s least important constituency, and they’ve responded by withholding the truth.
Build the system around the operator and the relationship inverts in the only direction that recovers the executive’s view. The system has to describe what the operator is doing, in language the operator already uses, with categories that match the categories on the floor. Operational events have to have names. Workarounds have to be unnecessary, because the system can already represent the situation. Once that’s true, operators stop fighting the system, the data becomes real, the aggregations become trustworthy, and the dashboard finally tells the executive something that isn’t an aggregate of fabrications.
This isn’t populism. The operator’s primacy here isn’t a moral claim about who deserves to win; it’s an observation about where the information lives. Software architecture isn’t a vote on whose interests count most; it’s a question of which design produces a system that works. The architecture that gives executives clean reporting turns out to be the architecture that puts operators first, because operators are the only people in a position to write down truth.
The thing nobody quite says
What never gets said cleanly, in the ERP industry, is that the executive-first architecture has also failed the executive.
The traditional ERP promise was a single source of truth, real-time visibility, executive dashboards driven by live data. Thirty years of vendors selling that promise, thirty years of customers signing for it, and the replacement-intent figures Gartner publishes (87% of organizations with an implemented ERP plan to replace or upgrade within three years[1]) are not just a measure of operational dissatisfaction. They’re a measure of how reliably the executive promise has been broken. The CFO bought single-source-of-truth and is running three reconciliations to close the books. The COO bought real-time visibility and reads dashboards that lag the floor by twelve hours. The CEO bought executive insight, and asks the COO what’s actually going on, because the COO knows and the system doesn’t.
Books that reconcile to a model that doesn’t match the operation are not the same thing as clean books. The accountant-first system delivered the first thing and called it the second. The operator-first system, by not aiming at executive reporting at all, ends up producing it as a side effect. When operators describe reality and the system projects reality into the books, the books come out correct in a way the chart-of-accounts-first model was structurally incapable of producing. Variance accounts shrink because there’s less fabrication compressing into them. Cost data is real because it’s calculated from what was consumed instead of from what got reported as consumed. The audit trail becomes meaningful, because every change carries the operational context that produced it. Dashboards lead the floor by milliseconds, because they read the operational store directly instead of waiting on a nightly batch. The CFO ends up with a closer book than they ever got from the system that was always trying to give them one.
It’s worth pausing on this, because it’s the part most readers won’t immediately accept. The accountant got worse books out of the system designed for accountants, and gets better books out of the system designed for operators. The reason is plain enough: book quality is downstream of input quality, and input quality depends on how easy and accurate the system makes it for the people who hold the truth to write it down. Designing for those people is the only way the books come out clean. Designing around them, which is what every accountant-first system has done, is the way the books come out only as clean as the operators were willing to make them, which has not, on average, been clean enough.
The executive doesn’t lose anything in the inversion. Reporting still exists, dashboards still exist, approval gates still exist; the CFO still closes the month and the COO still presents to the board. The shape of the executive’s experience is the same. What changed is the system underneath it, which is finally telling the truth instead of an aggregated fiction. Everything the executive thought they were buying is being delivered for the first time.
What we’re building, in those terms
Yggdrasil ERP is an operational engine. The schema’s spine is the operations of the business: work orders, receipts, picks, transfers, NCRs, audits, cases, opportunities, projects. The chart of accounts is real, complete, and correctly modeled, but it lives downstream of the operations rather than upstream of them. State engines govern operational entities, the audit log records operational mutations, the B2B Event Hub publishes them as they happen, and dashboards read the operational store directly. Mímisbrunnr, the canonical vocabulary the platform speaks, is a vocabulary of business nouns rather than ledger accounts, and the ledger meanings derive from the nouns.
The financial picture follows. We have not abandoned the books. We’ve moved them where they belong, which is downstream of the operation that produces them. In the architecture we are building toward, the accountant who used to spend a week each month reconciling subledgers gets a real-time, structurally correct general ledger as an automatic consequence of the operational record. Continuous visibility replaces the close-day wait. An auditor who asks “can you show me the source documents for this entry” gets a per-field delta with the operational context that produced it. None of this required a mode switch from operations to finance, because there is no mode switch: the operation and the finance are the same data, observed from different angles.
We did not invent the diagnosis. The information-systems literature has been documenting it since the late 1990s. Behrens and Sedera’s 2004 work on ERP shadow systems asked why shadow systems persist after implementation, and answered that the implemented schema does not cover the represented work.[2] The shadow systems are the bookkeeper’s inheritance made visible: the operational canon migrated out of the system because the system was built for the wrong purpose, and is now defended by the operators who maintain it and invisible to the executives reading the dashboards. The diagnosis is twenty-five years old. Building for it, instead of bolting more knobs onto the patient, is what we think is new.
Closing
ERP grew up in the back office. The chart of accounts became its spine because that’s what the customer at the time cared about and what the compute environment could afford to hold together. The architecture survived the conditions that produced it, and it now defines a category of software whose every module sits downstream of an accounting model that operations does not fit into. Operators write the closest legal answer, executives read aggregates of those answers, the books reconcile to a fiction, and the operational canon migrates into spreadsheets, whiteboards, and the institutional memory of supervisors. Vendors respond to the gap by selling configurability. Configurability makes the rigidity worse, because the spine the configurations bolt onto isn’t a spine that can carry the operation.
Yggdrasil ERP refuses the inheritance. Operations are first-class; the books are a derivation. State engines model what the floor is doing. The ledger projection happens in one place, declaratively, where the accountant can read it. The audit log records reality instead of a flattening of it. Operators get a system that can describe what’s actually happening; executives get a system that’s finally telling the truth about the operation, because it’s finally being written by the people who know what’s going on.
The inheritance has been compounding for thirty years. We’re done paying interest on it.
May 2026. Companion essays: “The Operational Canon” (architectural commitments that follow from this position) and “Where ERP Actually Breaks” (modal failure modes the inheritance produces in practice).
Torii, D. (2024, May 10). What IT Leaders Must Do to Avoid Disappointing ERP Initiatives. Gartner Research, Document ID G00812598. The 87% figure is reported on the basis of the 2023 Gartner ERP, Procurement, HCM and Finance Apps Survey. https://emt.gartnerweb.com/ngw/globalassets/en/chief-information-officer/documents/what-it-leaders-must-to-do-to-avoid-disappointing-erp-initiatives.pdf ↩︎
Behrens, S., & Sedera, W. (2004). Why Do Shadow Systems Exist after an ERP Implementation? Lessons from a Case Study. PACIS 2004 Proceedings, Paper 136. https://aisel.aisnet.org/pacis2004/136/ ↩︎