Most finance teams do not need another chatbot.
They need one repetitive job completed properly.
That might be matching supplier invoices to purchase orders. Checking whether a month-end reconciliation pack is complete. Preparing a collections list. Producing a cash-position draft. Or identifying exceptions before a finance manager reviews them.
The difference matters.
A chatbot waits for questions and produces answers. A finance job has inputs, rules, deadlines, systems, evidence, exceptions and an accountable owner. It may also affect cash, suppliers, customers and statutory records. “The answer looks sensible” is not a control.
Google Cloud’s 25 August announcement of Gemini Enterprise for Financial Services is a useful signal of where the market is moving. The company says useful financial AI requires more than model intelligence: domain expertise encoded into reusable skills, secure connections to trusted systems and data, agents that can operate inside real workflows, and governance across the whole setup. The launch brings those ideas into capital-markets and corporate-banking workflows; it is a vendor announcement, not independent proof of outcomes.[1]
The practical lesson for an SME is simpler:
Do not start by buying an AI finance assistant. Start by designing one governed finance job.
What a governed finance job looks like
A governed job is a bounded work package. It tells the digital coworker exactly what work it owns, what information it can use, what actions it may take and when a person must intervene.
Take invoice matching.
A weak instruction looks like this:
Review our invoices and help the finance team.
A governed job looks more like this:
For new supplier invoices, read the invoice, retrieve the matching purchase order and goods-received record, compare supplier identity, currency, amount, tax, quantity and payment terms, then prepare a match report. Do not change the ERP, approve a payment or contact the supplier. Route every mismatch and every missing record to the accounts-payable reviewer with the supporting evidence.
That specification creates operating boundaries. It should include at least seven parts.
- Named owner. A finance manager owns the job, its rules and its results. The agent does not own accountability.
- Permitted inputs. List the exact folders, inboxes, ERP records and reference tables it may read.
- Allowed actions. Separate read, draft and write permissions. A first pilot should usually read and prepare, not post or pay.
- Deterministic rules. Hard controls—such as tolerance limits, duplicate-invoice checks and mandatory fields—should run as fixed rules, not model opinion.
- Evidence requirements. Every conclusion should point back to the invoice, purchase order, receipt or ledger entry that supports it.
- Escalation conditions. Missing records, conflicting amounts, unusual suppliers and low-confidence extraction should stop the normal path.
- Maker-checker approval. The agent can prepare the work. An authorised person approves the consequential action.
This is what turns AI from a conversation into an operating component.
Put the model in the right part of the process
Finance work mixes two different kinds of tasks.
Some tasks need interpretation. A model can extract fields from differently formatted invoices, classify a supplier query, summarise a reconciliation note or explain why two documents appear inconsistent.
Other tasks need certainty. A purchase order either exists or it does not. A bank account either matches the approved supplier master or it does not. A duplicate invoice number either appears in the ledger or it does not. A payment amount either exceeds the approval threshold or it does not.
Do not ask a probabilistic model to improvise a hard control.
Use the model where language and variation make traditional automation brittle. Use deterministic logic where the business already has a rule. Then make the workflow preserve both the result and the evidence.
That is orchestration: different components doing the work they are best suited to do, under one controlled process.
A practical six-step pilot
An SME can test this pattern without redesigning the whole finance function.
1. Choose one repetitive job
Pick a task with enough volume to matter and enough historical cases to test. Invoice matching, completeness checks and document reconciliation are usually better starting points than forecasting or payment execution.
Write down the start event and the finished output. If the job cannot be described clearly, it is not ready for an agent.
2. Map the normal path and exception path
Show what happens when everything matches. Then list the reasons a case must stop: missing purchase order, amount outside tolerance, supplier-bank change, duplicate invoice, unreadable document or inconsistent tax treatment.
The exception path is not an edge case. In finance, it is often where the value and the risk sit.
3. Connect only what the job needs
Do not give the pilot broad access to email, ERP, shared drives and banking because those systems are available.
Give it the minimum records needed for the defined job. Use a dedicated identity. Keep write access off unless the pilot has proved it needs a specific, reversible write action.
4. Test against known cases
Build a test pack from completed work: straightforward matches, common exceptions and a small set of difficult cases. Compare the agent’s output with the approved historical result.
Track extraction errors, false matches, missed exceptions and unsupported conclusions. A polished explanation does not compensate for a missed duplicate or a fabricated reference.
5. Measure the job, not the demo
Use operating measures: cycle time per case, percentage routed correctly, evidence completeness, exception precision, reviewer correction rate and cost per successfully completed case.
Token volume is a cost input, not proof of capability. The useful question is whether the controlled workflow completes more good work with less manual effort and no weaker control.
6. Keep money movement outside the pilot
The first version should prepare and recommend. It should not approve invoices, release payments, alter supplier bank details or send collection messages without review.
Maker-checker is not anti-AI. It is how the business separates preparation from authority while the system earns trust.
Scale by reusing the job pattern
Once one job works, do not jump to a general autonomous finance agent.
Turn the proven workflow into a reusable skill: its instructions, permitted tools, test cases, evidence format, exception rules, approval gate and success measures. Then adapt that pattern to the next bounded job.
Invoice matching can lead to statement reconciliation. Reconciliation can lead to a month-end completeness check. Collections preparation can lead to customer-risk briefing. Each job may share components, but each keeps its own authority boundary.
This is how a finance digital coworker becomes useful without becoming vague or overpowered.
The model will keep changing. The operating design is the durable advantage.
Define the job. Constrain the access. Enforce the rules. Preserve the evidence. Keep a human accountable for the decision that moves money.
That is how finance moves from chat to execution—without surrendering control.
Sources
[1] https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-for-financial-services — Introducing Gemini Enterprise for Financial Services