We follow invoice INV-40218 from arrival to sealed record. You see the rules, the check before each action, the person who makes the hard call, and the audit trail. The run is simulated, and labelled as such.
- Run opened
- Invoice matched
- Actions passed
- Payment held
- Approver asked
- Declined and sealed
The setup
The invoice as it arrives.
Known supplier, correct amount, one changed bank detail.
INV-40218 comes with a purchase order attached, and nothing looks wrong. Only the bank account in the payment details has changed since the last payment. Swapping the bank account on a normal invoice is an old fraud.
- 2,400.00The amount. Above the autopay limit of 250.00, inside the purchase order.
- On fileA known supplier. Paid before, under the same name.
- Three-wayThe match passes. The purchase order and goods receipt agree with the invoice.
- One changeThe bank detail. DE89 ···· 4402 became DE44 ···· 9017 since the last payment.
The run, replayed
Six events, in the order they happened.
One simulated run, RUN-7F2K4, under signed manifest v14.
Scroll to replay, or pick an event.
01 · 14:31:52
The rules come first.
The rules are in place before the invoice arrives. Manifest v14 sets the spend controls, the matching rules, and least-privilege access to accounts payable only. The agent can't step outside them.
02 · 14:31:52
Each action is checked.
The policy engine checks each action before it runs. Scope, role and limits pass. The bank detail has changed since the last payment, so the engine flags it.
03 · 14:31:58
Routine steps go ahead.
Steps the policy already allows go ahead. The agent reads the invoice, matches the purchase order, drafts a message to the supplier and schedules the payment. Each step is checked and recorded.
04 · 14:32:00
The payment is held.
The bank detail was first seen today, so rule bank-detail-change holds the payment. The run asks the AP lead by name. They get the old and new detail, the invoice, and the rule that fired.
05 · 14:32:19
Declined, then sealed.
The AP lead declines the new account and asks for a call back to the supplier. The record is sealed with each action, the hold, the decision, their name and the policy version. Any later edit, by you, an admin or us, breaks the chain in plain view.
06 · replayed
Replay and export it.
When someone asks about the run later, it replays from the record. It uses the same inputs and policy version, and shows the outcome as sealed. The trail exports in open formats and can be read without Gatehouse installed.
- 0114:31:52run opened · RUN-7F2K4 · manifest v14
- 0214:31:52policy check · scope, role, limits · pass
- 14:31:52bank detail changed · flagged
- 0314:31:58invoice matched · INV-40218 · three-way
- 0414:32:00payment held · rule bank-detail-change
- 14:32:00routed to ap-lead · evidence attached
- 0514:32:19declined · ap-lead · supplier did not confirm the change
- 14:32:19sealed · sha-256 27c9b0e5 · chain intact
- 06replayedsame inputs · manifest v14 · as sealed
More on these steps: Runtime enforcement, Approvals, What reviewers ask.
How it is built
Two numbers you can check.
The policy engine checks each action before it runs. An action the manifest does not name is refused, and the refusal is recorded.
1
named approver.
Each hold goes to one person, with the evidence.
2
approvers to override a block.
Both names are saved with the override.
Three parts of each run.
A policy check before each action, a person for the hard call, and a sealed record you can still read months later.
Each action is checked before it runs. The policy engine sits in the path of each action, so nothing can go around it.
A person makes each hard call. When a rule holds an action, the run pauses and goes to one approver with the evidence. Their decision is saved with their name.
Each run is sealed into a record. Months later, it still shows what happened, who decided, and which policy applied.
What the run leaves behind
Four things. The manifest it ran under, the check it passed, the hand-off of the hard call, and the sealed record.
Manifest v14, signed. The five gates your team wrote: scope, role, limits, review and seal. The run used this version and no other.
The check before each action. Scope, role and limits pass, and so does the match. The bank detail has changed since the last payment, so the engine flags it. The routine steps go ahead and the payment waits.
The AP lead, asked by name. The payment stops before it leaves, and the AP lead gets the case with the evidence gathered. They decline the new account and ask for a call back to the supplier. Nothing goes to the new account until the supplier confirms it another way.
RUN-7F2K4, as sealed. Lines are added in order and chained by SHA-256, so the record is tamper-evident. The decision and the reason sit under the AP lead's name, next to the evidence they saw. If anyone edits a line later, the chain breaks in view.
One signed manifest
Five gates, written by your team and versioned like code. Gatehouse runs that version and no other, and refuses anything it does not allow. Here are the five gates in manifest v14, the version this run used.
- 01ScopeWhat the run may touch. RUN-7F2K4 could touch accounts payable only.
- 02RoleLeast-privilege access for the agent. Here, it acts as ap-agent.
- 03LimitsSpend controls and matching rules: three-way match, autopay limit 250.00.
- 04ReviewWho decides the hard calls, and the rules that send a run to them. Here, the AP lead, and rule bank-detail-change held this payment before it left.
- 05SealEach action, hold and decision, added in order and chained by SHA-256. Sealed at 14:32:19, chain intact.
What to expect from a first walkthrough
It is a 30-minute call with no slides. We bring manifest v14 and the sealed record of INV-40218. You bring one live process and your reviewers' questions.
Questions
Four questions about this run.
Short answers you can read before any call.
Then no one is asked to step in. The run goes end to end under runtime policy enforcement, and the record is sealed. People only see the runs that need them, and the record is complete either way.
Then that is their decision, saved under their name next to the evidence they saw. A block is harder to wave through. Overriding one needs a second approver, and the override is recorded too.
The check sits in the path of each action, so it adds some time. On this invoice, the other choice was an unchecked payment to a changed bank account. We think the check is worth that time.
No. It is a simulated run, labelled as such wherever it appears. The changed bank detail is a real and old pattern. The steps on this page show how Gatehouse handles it.
Walk through a runwith the team behind it.
Or see the platform first