Every finance team asks the same five questions before they let anything near the ledger.
Here are the answers, in the order they normally get asked — including the one about AI.
Question 01
“Will our data be used to train an AI?”
No. Not now, not later, not anonymised.
There are two separate things inside a bot, and neither trains on your data.
The rules engine — matching, tolerances, posting logic, approval routing — is
deterministic code. There is no model in it at all. Same input, same output,
every time, and you can read the rule in plain English.
Where a model genuinely helps — reading a supplier PDF, suggesting a code for an
unfamiliar expense, drafting variance commentary — we use enterprise processing
only, where the provider is contractually barred from training on customer content
and retains nothing once the call returns. The provider and the terms are named in
your blueprint before you sign it.
Question 02
“Where does our data actually sit?”
Where it sits today. We build inside your tenant.
Your QuickBooks, your Xero, your NetSuite, your cloud storage, your Microsoft or Google
tenant. The bot runs against your systems with credentials you issue and can revoke.
There is no FinOps Robotics data lake, because we don’t want a copy of your ledger
any more than you want us to have one.
Where a step genuinely cannot run in your environment, we say so in the blueprint,
name exactly what moves, why and for how long — and you approve it or we design
around it.
Question 03
“Who on your side can see our numbers?”
Named people, listed in the engagement letter.
Not “our team”. Names. Usually two: your engagement lead and your build lead.
Each holds their own credentials under your identity provider, with MFA enforced by you
rather than promised by us, and you see them in your own user list.
No offshore subcontracting, and nobody is added to your systems without your written
approval first. Every access we hold is one you granted and can pull in a single click,
without asking us.
Question 04
“What can the bot actually do?”
Only what its scope says. And never move money.
Permissions are least-privilege and written into the blueprint object by object.
During scoping the access is read-only — we can size the work without write rights
at all.
No bot we build ever holds payment initiation rights, user administration or the
ability to delete master data. A payment file is prepared for a human to release,
through your bank, with your token, on your device.
Least privilege, in practice
What we ask for at each stage.
Access goes up only when the stage genuinely requires it and comes back down when it doesn’t.
StageAccess we holdWhat it cannot do
First sessionfree, ~5 daysRead-only reports or exports you send us. Often no login at all.Change a single record
Blueprint1–2 weeksRead-only, plus a sandbox or test company of your own.Touch live data
Build & parallel run2–6 weeksWrite access scoped to the named objects in the blueprint, in parallel with your team.Post without your sign-off
RunongoingThe bot’s own service account, scoped to its rule set, fully logged.Release a payment
Neverat any stagePayment initiation · user administration · master data deletion · bulk export outside your tenant—
Where AI is used — and where it isn’t
Most of this isn’t AI at all.
“AI” has become a synonym for automation. It shouldn’t be. Here is the honest split
inside every bot we build.
Deterministic code — no model involved
Matching invoices to purchase orders and receipts
Tolerance and variance rules
Every posting and journal the bot makes
Approval routing and threshold rules
Duplicate detection and payment screening
Intercompany matching and elimination
Consolidation, FX translation and the statements
Same input, same output, every time. Readable, testable and explainable to an auditor line by line.
Model-assisted — always behind a gate
Reading a supplier PDF or a photographed receipt
Suggesting a code for an expense it hasn’t seen before
Fuzzy vendor name matching for duplicates
First-draft variance commentary for your review
Ranking an anomaly queue by value at risk
Every one of these outputs passes either a deterministic check or a human gate before
it reaches your ledger. A model never posts anything on its own authority and low
confidence routes to a person rather than into the accounts.
Our own house
The controls we run on ourselves.
We sell control environments. It would be absurd not to have one.
Access hygiene
MFA on every account without exception. Credentials in a managed password vault, never in email, chat or a spreadsheet. Encrypted devices, no client data on personal machines.
People
NDA signed before the first call, not at contract stage. Access removed the day someone leaves an engagement. No subcontracting of client work without your written consent.
Leaving well
End the engagement and our access is revoked the same day, working copies destroyed and every rule set and document handed over. The bots keep running without us.
What we don’t claim
We are not ISO 27001 certified and we are not SOC 2 audited. Plenty of firms our size
imply otherwise with a badge on a footer; we would rather you heard it from us than
found out in due diligence.
What we offer instead is verifiable rather than certified: we work inside your tenant
under access you control, so your existing certifications and controls govern the data,
not ours. You can revoke us in one click, audit every action from your own logs and
check the work yourself during the parallel run before any bot has authority over
anything.
If your procurement process requires a certified supplier, tell us in the first session.
We will tell you honestly whether we clear your bar today rather than waste six weeks
of your time.
Bring your security team to the first session.
Genuinely — it is a shorter conversation at the start than at contract stage and we
would rather design around your constraints than discover them later.