The position  /  Controls
CTLControls & deployment

Segregation of duties, written into the tool bindings.

Every finance buyer has been shown an “AI” that turned out to be OCR with a rules engine. This page is the answer: how a desk is built, what it is physically bound to, and the eight stages before it touches a live ledger.

22 days to livePreparer ≠ reviewerNothing posted autonomously
The architecture

Three layers, and the middle one is the product.

Rules — approval matrices, coding rules, tolerance thresholds, policy limits, the client's own chart of accounts — live in code, in the action handler. A vendor writing a persuasive email does not move a tolerance, because the model is not the thing enforcing it.

Bindings — what each agent may physically call. This is the layer that makes the control real. The payables agent is bound to capture, code and match. It is not bound to a payment tool, a bank-detail field or a posting endpoint, so it cannot reach them by any route: not by instruction, not by error, not by a user asking it nicely.

Knowledge — the client's chart of accounts, coding history, vendor and customer master, prior-period treatments, policy documents and precedent decisions — sits in a retrieval index scoped to your desk alone. The desk codes an invoice the way this client has always coded it, not the way invoices are generally coded.

Judgement sits outside all three, with your reviewer and the client's controller. By design, not as a fallback.

A control written in a prompt is a suggestion. A control written in a tool binding is an absence — the capability does not exist, so it cannot be exercised, argued past or misconfigured.
Deployment

Eight stages, twenty-two days.

  • Chart of accounts and policy capture  Day 1–4

    The client's chart of accounts, coding rules, approval matrix, tolerance thresholds, expense policy, credit terms and close calendar are written into a machine-readable spec. Every rule traced to a client document or a signed-off decision. Anything the client cannot answer is logged as an open item — and in finance there are always some, usually around who may approve what at which value.

  • Ledger and history indexing  Day 3–8

    Coding history, vendor and customer master, prior-period treatments, recurring journals, precedent decisions and the standing schedules are indexed to your desk. This is what lets the desk code a recurring vendor invoice correctly in week one instead of month four — it has read how this client coded the last two hundred.

  • Duty definition  Day 5–10

    Each agent is written a role in the language a finance function already uses: preparer or reviewer, never both. What it owns, what it may complete alone, what it must hand to a human, and what it is measured on. Published in full on the desk.

  • Tool binding and control build  Day 6–11

    Each agent is bound to a specific set of ledger actions and client-system endpoints and to nothing else. Payment tools, bank-detail fields and posting endpoints are bound to no agent at all. Tolerances, thresholds and dual-verification requirements are added here, in code. This is the stage a client's auditor will ask about, so it is documented as a control narrative you can hand over.

  • Bench testing  Day 9–16

    Every agent runs against replayed historical transactions with known correct outcomes, drawn from the client it will serve. Accuracy measured per transaction type — a desk that codes 98% of invoices correctly can still be poor on intercompany or on multi-currency, and one headline number hides that. Nothing leaves the bench until it clears its own threshold, and every failure is traced to a missing knowledge item or a badly stated rule and fixed at source.

  • Parallel run  Day 16–20

    The desk processes live transactions and posts nothing. Every output queues for review beside the client's own processing, and the two are compared line by line. This is the finance equivalent of a parallel run on a system migration, and it is the stage that earns the client's trust — they can see the desk agreeing with them before it replaces anything.

  • Staged handover  Day 20–22

    Cycles are handed over one at a time, lowest risk first: master data cleansing, then expenses, then reconciliation preparation, then payables. Approval, posting and payment never transfer at all. Each handover is a decision with a name against it, recorded in the ledger.

  • Continuous control  Ongoing

    QC re-checks 200 random items every week, weighted to coding and reconciliation treatment. Every reviewer overrule is logged with a reason and reviewed for pattern. Chart-of-accounts changes, policy changes and new approval limits are versioned updates to the spec, pushed and re-benched before they take effect. Every action and its inputs are retained 24 months in an append-only trail.

Segregation of duties

The oldest control in accounting, applied to agents.

The principle is four hundred years old and it is the first thing any auditor tests: the person who prepares a transaction is not the person who reviews it, and neither of them releases the money. That maps onto an agent desk exactly.

Preparers · cannot review

Payables · Receivables · Reconciliation · Expenses · Close · Master Data

Capture, code, match, schedule and analyse. Each is bound to the tools of its own cycle and to no review or approval endpoint. A preparer cannot mark its own work as checked.

Reviewers · cannot prepare

Control · Variance · Audit · Reporting

Screen against policy and threshold, flag unusual movement, test the completeness of the trail, and assemble the pack. Bound to read and flag endpoints only. A reviewer cannot create or amend a transaction.

Approvers

Human only

Payment release, journal posting, bank-detail amendment, credit notes, write-offs and reconciliation sign-off. Held by your reviewer under a documented approval matrix, or by the client's own finance function. No agent is in this chain, and no configuration puts one there.

Honest limits

What the desk does badly.

Any vendor who will not answer this is selling you something.

  • First-time vendors and one-off transactions with no coding precedent. It proposes and flags its own uncertainty — but it flags a lot in month one.
  • Judgemental provisions and anything requiring a view on the future. It gathers evidence; it does not form an opinion.
  • Reconciliation breaks where the client's own records are internally inconsistent. Those escalate, and there are always some.
  • Poor-quality source documents. A photographed receipt at an angle in bad light is a bad input, and no amount of processing fixes it.
  • Anything where the client's policy is silent. It will not fill the gap with a reasonable-sounding treatment, which is correct but does mean more items in your queue.

Read the duty roster next.

Every agent published as a role, marked preparer or reviewer, with what it may complete alone and what it must hand over.