Illustrative scenario with a fictional organisation. Not a customer reference, result or forecast.
Dozens of sites, one fund, and a board that wants proof.
A bakery-café franchisor saw AI arriving in rosters and orders. Its board asked what each fund dollar did, and who approved every payment. Email could not say.
One proposed site payment, five governed steps
Hollowbrook Bakehouse is fictional. A restricted agent prepares a synthetic site payment for review. Teradius does not pay, transfer or hold money and gives no financial or tax advice.
A Hollowbrook agent proposes a fictional AUD 6,350 site payment. One exception is held because the supplier record changed; it is reviewed and resolved once the record is verified. Finance manager Lena Ortiz approves the exact amount, recipient and version, AUD 6,350 to Site supplier (fictional), payment version 2, under reference R-52718. Authority is re-checked at execution. The receipt carries the same reference, R-52718, with the decision record and board pack.
What would change, as designed A supplier payment would go out only as the approver saw it.
Read the full scenario
At a glance
- Organisation
- Hollowbrook Bakehouse (fictional), an Australian franchised bakery-café network
- Size
- Several dozen sites across two states; a few company-owned, the rest run by single-site and multi-site franchisees
- Entities
- The franchisor company, a central bakery that supplies the network, a small number of company-owned sites, and a specific-purpose fund administered for franchisees
- Customers and stakeholders
- Franchisees; approved suppliers; a franchisor board
- Governance
- A franchisor board; a head of finance and a head of people at head office
- 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. Quick-service restaurants pack: in design.
The situation
Hollowbrook Bakehouse (fictional) is a franchised bakery-café network across two states. A few sites are company-owned; the rest are run by franchisees, some with one site and some with several. A central bakery supplies the network.
Head office does what franchisors do with money. It bills royalties and contributions to a specific-purpose fund, and must account to franchisees for what the fund paid for. It pays suppliers for the company-owned sites and the bakery. It runs payroll on hospitality awards for its own staff. And it reports to a board that has watched the questions put to franchisors sharpen: about the fund, about supplier payments, and about pay across a network it does not directly employ. Teradius does not answer the last of those; this scenario is about what head office can show for its own money and its own payroll.
The problem
AI arrived at the sites before it arrived at head office. Franchisees began using tools that propose rosters and supplier orders. Head office's own finance team wanted agents to match supplier invoices for the bakery and the company sites. None of this was unwelcome, but each proposal commits money or hours, and each one was approved, if at all, by a reply to an email.
The board's questions had become specific. Can we show what each fund dollar did, and give franchisees a statement they can trust? Who approved each supplier payment, and did they see the account it went to? Can we show that our own payroll was run the way we say it was?
Several dozen sites, a central office and an email trail could not answer any of them without days of work, and the answers aged as soon as they were written.
What they did with Teradius
In this scenario, the franchisor moves its own ledger and payroll into Teradius and keeps its banking and supplier-payment systems 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.
Supplier payments, supplier changes and fund disbursements become catalogue actions. Each 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, including the recipient and the amount. A bank detail changed after review is refused before the connected system pays, and a repeated request is never acted on twice. (Core: true now.)
Agents propose matches within a budget. The invoice-matching agent has a restricted identity, proposes only catalogue actions, carries a budget and can be stopped at any step; a person can complete the same job without it. (Agents: true now; tested against recorded model responses and not yet run against a live model.) The approval screen that shows a proposal's AI origin, reason and exact effect is in development.
The fund with one definition per figure. Fund contributions, disbursements and balances are recorded in the ledger, where posted entries are not altered and corrections are new entries. Each figure in the fund statement takes one published, versioned definition with lineage back to the records, so the statement franchisees receive and the figures head office works from are the same figures. (ERP and Intelligence: true now.)
Payroll in the same records. Head office's payroll runs post into the same ledger, with receipts and an audit trail that records every change with who made it and when. (ERP: true now.) Australian payroll rules are the Australia pack, in development, so the scenario describes them as designed to be carried by the pack. Franchisees' own payroll stays with the franchisees unless they use Teradius too; the scenario does not have head office seeing it. Nothing here assesses or certifies compliance with any workplace law.
A board pack with guardrails. The board's directives are set up with key results and guardrails for wastage and labour cost. Health is computed from published definitions, and a sales target met while a guardrail is breached is reported as unhealthy. Packs are frozen at issue. (Strategy: true now.)
Venue operations, when the pack is built. The quick-service restaurants pack is in design. It is designed to hold venue operations, menus, orders and shift reporting, with the books in the same records, so that a roster or supplier order proposed at a site would take the same approval path as any other action. Nothing in this scenario relies on it.
What would change
Qualitatively, and as the product is designed to work:
- A supplier payment would go out only as the approver saw it, and a bank detail changed after review would be refused before the connected system pays.
- Franchisees would receive a fund statement in which every figure traces to its definition and its records.
- The board would read a pack frozen from published numbers, with a sales target met while a guardrail breaches shown as unhealthy rather than hidden in the average.
- Head office could show, for its own payroll and supplier payments, who did what and when, from the record rather than from memory.
- Rosters, orders and the rest of venue operations would join the same records once the quick-service restaurants pack is built.
Our franchisees were never asking us to slow down on AI. They were asking us to be able to show our working. Being able to show our own working is where that starts.
— Head of Finance, Hollowbrook Bakehouse (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.
- The approval screen and accounting connectors 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.