Recent fintech research has put a useful number on an old frustration: UK businesses are still losing several days a month to manual finance administration. The headline is easy to interpret as a spreadsheet indictment. In practice, spreadsheets are rarely the root cause. The deeper problem is that finance work is a chain of handoffs, exceptions, approvals, and evidence checks that no single system models well.
That distinction matters to engineers building financial products. Replacing a spreadsheet with a dashboard does not remove the work. It often just moves the same reconciliation, chasing, and review tasks into a prettier interface. The better target is the workflow around the number.
The hidden cost is coordination
Consider a routine supplier payment review. Someone downloads a bank statement, someone else checks an invoice, a third person asks whether the purchase was approved, and a manager reviews an exception in a chat thread. The final accounting entry may take seconds. The surrounding coordination can consume hours.
This is why “automation rate” is a weak metric on its own. A process can automatically import 98% of transactions and still feel manual if the remaining 2% are ambiguous, high-value, or impossible to explain later. Those cases create queues, duplicate questions, and last-minute close pressure.
A useful finance workflow should answer four questions for every material decision:
- What source records were considered?
- What rule or model produced the proposal?
- Who reviewed or changed it?
- What should happen if the same event arrives again?
The fourth question is the engineering detail that gets missed most often. Financial integrations retry. Webhooks arrive out of order. A bank feed may restate a transaction. Without idempotency and a stable event identity, “automation” can create duplicate work or duplicate entries.
Design the exception path first
A common implementation pattern is to optimize the happy path and add an exception screen later. For finance, reverse that order. Start by defining what an operator needs when the system is uncertain.
An exception record might contain:
{
"event_id": "bank_2026_09_19_004821",
"amount": 1840.50,
"currency": "GBP",
"candidate_account": "software_expense",
"confidence": 0.71,
"evidence": ["bank:004821", "invoice:INV-8821"],
"reason": "Vendor changed legal name",
"state": "needs_review"
}
The important fields are not decorative metadata. event_id supports deduplication. evidence lets a reviewer inspect the underlying facts. reason tells the next person why the system stopped. state makes ownership and queue behavior explicit.
A reviewer should be able to accept the proposal, edit it, reject it, or request more evidence. Each action should append an event rather than silently overwrite history. That gives the finance team a usable audit trail and gives engineers a reproducible way to debug production behavior.
Keep automation proposals separate from accounting decisions
AI and rules engines are good at producing candidates. They are less useful when their suggestions are treated as invisible truth. A practical architecture separates three layers:
- Observed facts: imported transactions, invoices, contracts, and timestamps.
- Proposed interpretation: a suggested match, category, accrual, or anomaly flag.
- Accepted decision: the reviewed result that affects the ledger or reporting output.
This separation makes it possible to improve a model without rewriting the company’s history. It also lets a controller ask a precise question: “What did the system suggest on Tuesday, and why did we override it?”
Products such as Portali are interesting in this context because the valuable feature is not merely importing finance data. The useful capability is tying a proposed action to its source evidence and its review state, so an operator can move from “something needs attention” to “here is the decision and why it is safe.” That is a workflow improvement, not a sales promise.
Measure minutes returned to the team
If a finance automation project is working, measure more than straight-through processing. Track:
- median time from exception creation to resolution
- percentage of exceptions with complete source evidence
- duplicate events prevented by idempotency
- number of follow-up messages per close item
- percentage of accepted proposals later reversed
- time spent preparing explanations for reviewers or auditors
These metrics expose whether the system is actually reducing coordination. A lower message count and faster exception resolution may be more valuable than another percentage point of automatic categorization.
The practical takeaway
The current automation gap is not proof that finance teams need one more generic dashboard. It is evidence that financial work needs better representations of uncertainty, ownership, evidence, and decisions.
For engineers, that means treating the exception queue as a first-class product surface, designing for retries from day one, and preserving the difference between a machine proposal and a human-approved accounting outcome. For finance teams, it means asking vendors to demonstrate the review path, not just the import flow.
The spreadsheet is often where the symptoms become visible. The real opportunity is to build a system where every important number has a source, every uncertain interpretation has an owner, and every decision can be explained without reconstructing a week of chat history.
Top comments (0)