What is accounting policy as code, and why would I want it?
Your policy manual says how a transaction should be treated. Your ERP has that treatment hardcoded somewhere in a subledger, written by somebody who read the manual once. Accounting policy as code closes that gap: the policy is written in a small language, versioned, tested against worked examples before it can be promoted, and consulted by the posting path itself. A document arrives, the policy in force on that document's own date decides its treatment, and the journal cites the clause and the exact artifact it executed.
The gap this closes
Every finance function has a policy manual and an ERP configuration, and they disagree. Not because anybody was careless, but because the manual is prose and the configuration is a set of account mappings, and there is no mechanism by which changing one changes the other.
The cost shows up at audit as a question nobody can answer quickly: why was this treated that way, in March, under the policy that applied then. The answer lives in somebody's memory, a change ticket, and a mapping table that has been edited eleven times since.
What a policy actually contains
Its scope: which entities, which books, which currencies, which event classes. Its effective dates. Its precedence against other policies that might claim the same event. The conditions under which it applies. The evidence it requires before it will decide anything at all. The postings it determines. The materiality above which it escalates rather than deciding. And the worked examples that must pass before it can be promoted.
That last one is the part people underestimate. A policy is promoted by a second person and only if its own fixtures pass, so a policy that would have produced a different number than its author intended cannot take effect.
What it looks like in the ledger
An imported service invoice from a supplier outside the country is a reverse charge: the expense at net, input tax recoverable, output tax payable, and the payable. Four postings. The default treatment in most systems is two, with the tax folded into the expense.
Both of those balance. That is the whole point. Nothing in a conventional system catches the difference, and the journal that results carries no indication of which treatment was applied or why. Here the journal names the policy and the clause, and the determination behind it records the artifact hash of the exact policy version that executed.
Why it is a language rather than a rules table
A rules table with enough columns to express a real policy becomes a programming language with no syntax, no tests and no version control. Better to admit it is a language and give it those things.
It is deliberately not a general one. There is no user-defined control flow, currencies must agree before amounts can be compared, and a policy that does not handle every branch of its own condition will not compile.
What this does not do
Two of five event classes consult it today: a supplier invoice being entered and a customer invoice being raised. Payments, cash receipts and manual journals still receive the treatment the subledger code applies. Policy replay, re-deriving the ledger under a revised policy, needs an event log that is not built yet.