Illustrative scenario with a fictional organisation. Not a customer reference, result or forecast.
When an agent prepares the payment run, who approved it?
A family-owned distributor wanted AI in accounts payable. Its audit committee wanted to know who approves, against what, and how the board would know.
One proposed payment run, five governed steps
Barrowmere Industrial Supplies is fictional. An accounts-payable agent prepares a synthetic payment run for review. Teradius does not pay, transfer or hold money and gives no financial or tax advice.
A Barrowmere AI agent proposes an AUD 84,200 run covering 18 invoices. Two exceptions are held and reviewed: one is resolved and one invoice is rejected and removed. Finance manager Mia Chen approves the exact run of AUD 79,950 to 17 suppliers, run version 2, under reference R-88213. Authority is re-checked at execution. The receipt carries the same reference, R-88213, with the decision record and board pack.
What would change, as designed A changed bank detail would no longer travel silently with an invoice.
Read the full scenario
At a glance
- Organisation
- Barrowmere Industrial Supplies (fictional), a family-owned distributor of industrial and safety supplies
- Size
- Mid-sized: branches in several states, a few hundred staff
- Entities
- A trading company in each state, acquired businesses kept as their own companies, and a property company
- Customers
- Councils, state agencies, and mining and construction contractors
- Governance
- Second-generation family ownership; a board with independent directors and an audit committee
- Teradius used in this scenario
- Core (approvals, receipts, audit trail): true now. Agents: true now, tested against recorded model responses and not yet run against a live model. ERP and Intelligence: true now. Strategy (the Board Room): true now. Approval screen: in development. Connectors to existing accounting systems: in development. Australia pack: in development. Evidence of the AI run itself: in design.
The situation
Barrowmere Industrial Supplies (fictional) grew the way many distributors do: a branch at a time, and an acquisition at a time. Each acquired business kept its own company, its own chart of accounts and most of its own habits. The second generation runs the group now, with a board that includes two independent directors.
Its customers include councils and state agencies, which bring long tenders, strict invoicing rules and, lately, a new question in the procurement paperwork: how do you use AI in delivering and billing this contract?
Finance is a small team for the volume it carries. Thousands of suppliers, high invoice counts per dollar of margin, and approvals that happen by email, often in the evening.
The problem
The finance director wanted AI agents for the work that fills the team's days: matching invoices to orders and receipts, and preparing payment runs. The branches wanted faster supplier onboarding. Both are reasonable, and both put software close to money.
The audit committee's question was simple. If an agent prepares a payment, and a supplier's bank details were changed by an email nobody verified, who approved the payment, against what, and how would the board find out? Payment redirection through changed bank details is a fraud finance teams across Australia have been warned about, and the first payment to the new account is the loss.
Underneath it sat the older problem: several entities, several charts and a monthly board pack that was a reconciliation exercise before it was a pack. Directors trusted it because they had to, not because they could check it.
What they did with Teradius
In this scenario, Barrowmere (fictional) moves its entity ledgers into Teradius and keeps the systems that buy, pay and bank where they are, with Teradius in front of them as the approval and evidence layer. Connectors to existing systems are in development; the scenario assumes them. Teradius does not pay, transfer or hold money; the connected system pays.
Payment runs and supplier changes become catalogue actions. A supplier-master change or a payment run is proposed, reviewed in plain language, approved by a named person with a stronger sign-in step, and executed only after authority is re-checked. The approval is bound to the exact effect: the recipient, the amount and the version of the record the approver saw. A change after review is refused before the connected system pays. A repeated request returns the first result and is never acted on twice. (Core: true now.)
Agents propose; people decide. The matching agent has a restricted identity with only the roles it was given. It can propose only what the catalogue allows, carries a budget, and can be stopped at any step. If no model is available, a person can complete the same job alone. (Agents: true now; tested against recorded model responses and not yet run against a live model.) The plain-language approval screen, which shows the AI origin, the reason and the exact effect, is in development, and the evidence of the AI run itself, the model, its version and the context it saw, is in design.
One ledger model across the entities. Each company keeps its own records, under one set of permissions and one audit trail, with every change recorded with who made it and when. Posted entries are not altered; corrections are new entries. (Core and ERP: true now.) GST and activity statement figures are computed from the ledger (ERP: true now; lodgement is not included). The Australian chart of accounts and Australian payroll rules are the Australia pack, in development, so the scenario describes those as designed to be carried by the pack.
Numbers with definitions, and a board pack nobody prepared. Each metric the board sees takes one published, versioned definition, with lineage back to the records and the time its sources were last updated. The Board Room builds packs only from those definitions and freezes them at issue, with any restatement shown beside the figure it replaces. (Intelligence and Strategy: true now.)
Evidence a director can check. Decision records and evidence packs are signed and chained, and can be checked without relying on Teradius. (True now; today this is a command-line check rather than a product screen.)
What would change
Qualitatively, and as the product is designed to work:
- A changed bank detail would no longer travel silently with an invoice. The approval is to the recipient and amount the approver saw; anything else is refused before the connected system pays.
- The board would read a pack that nobody prepared, and could trace any figure back to its definition and its records.
- The agents the finance director wanted would be in use for what they are good at, proposing, while the decision and the proof stay with people.
- When a government customer asks how AI is used in billing its contract, the answer would be a record, not a reassurance: who proposed, who approved, what exactly, and when.
Our directors never doubted the team. They doubted whether anyone could prove it. Now the proof is the way the work gets done.
— Chief Financial Officer, Barrowmere Industrial Supplies (fictional). An invented line for this fictional scenario; not a testimonial and not a statement by any real person.
True today and bounded
- Approval binding, execution re-checks, receipts and signed decision records are true now on synthetic data.
- Accounting connectors, the approval screen and the Australia pack are in development.
- The agent runtime has been tested against recorded model responses and has not yet run against a live model. AI-run evidence is in design; no payment is shown.
True now means built and working in our pre-release environment on synthetic data. In development means being built now. In design means designed, not yet built. Nothing on this site is generally available.
Teradius is pre-release, and early access is by invitation.
If your board or finance team is deciding how AI agents may be allowed near money, request a briefing.