There are two versions of every control. There is the one in the binder — the narrative that says approvals are required over a threshold, that the person who enters a payment cannot also release it, that posting periods are locked after close. And there is the one in the system — what the configuration actually enforces when someone tries to do those things. Audit is where the two versions are introduced to each other, and it does not always go well.

The common assumption is that audit readiness is a documentation exercise: when the auditors arrive, you produce the narratives, walk them through the binder, and demonstrate that controls exist. But a modern auditor doesn't just read the binder. They test the system. They try to post to a closed period. They check whether one user ID can both create and approve a vendor. A control that lives only on paper is a finding waiting to be written.

A control described in a document but not enforced in the system is just a sentence. The auditor tests the system.

The control is the configuration

Take segregation of duties. As a policy it is a sentence: the person who can enter a payment cannot be the person who releases it. As a control it is a configuration — a set of role and authorization assignments that actually prevent one user from holding both capabilities. The narrative describes the intent; the configuration is the control. An auditor confirms the second, not the first, because intent doesn't stop a payment and configuration does.

The same holds up and down the list. Approval thresholds are workflow configuration. Three-way match is a setting that either blocks a payment without a matching receipt and order, or doesn't. Posting-period locks are a control table. Whether a change to a posting rule is even recorded is a logging configuration. Every one of these is a control that lives in the system, and "audit-ready" means the system is configured to enforce what the binder claims.

Where the gap shows up

The expensive moment is the one where the narrative and the configuration disagree. The binder says approvals are required above a threshold; the workflow was never configured to enforce it, and for two years approvals were a matter of habit, not control. The policy says duties are segregated; a handful of power users quietly accumulated both roles during go-live and nobody pulled them back. On paper, a control. In the system, nothing. That gap is not a documentation problem you can write your way out of at year-end. It is a deficiency — and it was a configuration choice all along.

Controls that live in config, not the binder
  • Segregation of duties. Roles and authorizations that actually prevent one person from holding incompatible capabilities.
  • Approval thresholds and three-way match. Workflow and matching rules that block the transaction, not just describe that they should.
  • Posting-period locks and change logging. What the system stops after close, and whether changes to the rules are recorded at all.

Build it in, and the binder writes itself

The discipline is to treat audit readiness as a configuration decision made during the build, not a binder assembled at year-end. Configure the control so the system enforces it. Turn on the change log so the evidence accumulates on its own. Do that, and the narrative becomes a description of something true rather than a wish — and the binder largely writes itself, from a system that already does what it claims.

This is why we ship every flow with its control narrative attached. It isn't extra work bolted on for the auditors. A flow that ships with its control narrative isn't extra work — it's the difference between describing audit-readiness and actually having it.