From blind spend to an Operational Brain

Control was not lost in the data. It was lost between whoever spent the money and whoever answered for the margin. The property operated remotely on ~USD 1.9M of annual sales against ~USD 0.55M of annual operating cost, execution of spend was delegated to an external operator in the field, and seasonality concentrated almost all income into a few weeks of harvest — so the margin on a sale that happens once a year depended on a control that never operated in real time. Field, administration and back office ran in three channels that shared no data. Authorisations and supporting documents lived in chat groups and spreadsheets, so nothing could be tied together or audited afterwards. Budget-versus-actual appeared only at month-end close, which meant overdrafts were detected once they were already irreversible, 30 to 45 days after the spend that caused them.

• Stage 1 — capture. Photo capture of every expense in the field, with OCR extracting amount, date and supplier, validating the supplier against the tax authority's records and posting it straight to a cost centre. In parallel, automatic ingestion of every electronic invoice issued to the company into a single source of truth, independent of the operator's own report.
• Stage 2 — flows. A live budget-versus-actual board by account, one-click approvals from a phone with an immutable trace, and a three-way match tying purchase order, invoice and payment together.
• Stage 3 — the Operational Brain. A read-only batch layer over the ERP, the bank and the tax authority records: it downloads, structures and cross-checks each morning. It is a layer, not a replacement — nothing was migrated, and it never writes back into the source systems.
• Ranking by money. The layer detects inconsistencies against the state of the art and orders the leaks by the amount at stake, with every figure labelled Found or Inferred and its source linked.

30 → 0 days

budget-vs-actual latency

~110 h/month

released from manual data entry

~19%

of purchase spend at risk as VAT credit

• ~3,300 transactions a year were being handled by hand. The opening audit found eight leak points: the agency problem, four petty-cash floats, chat-based authorisation, three-way invoice reception, month-end-only budget-versus-actual, ~19% of purchase VAT at risk, +110 hours/month of manual entry, and no PO–invoice–payment match.
• Every amount in the leak ledger below is in the local currency of the case, unconverted. None of them is USD — the operation itself runs on ~USD 1.9M of annual sales.
• Leak ledger, ranked by money: 67.4M of VAT credit at risk, MEASURED (19% of a 354.6M taxable base); 14.0M of VAT lost to expired deadlines, ESTIMATED; 9.0M of unalerted overdrafts, ESTIMATED. Total in play: 90.4M per year.
• Budget-versus-actual latency 30 → 0 days. Deviation by account is flagged on the day it occurs, not at month-end close, so an account running over budget is a decision the same morning instead of a post-mortem.
• Budget execution by account on the live board: fertiliser 62%, labour 71%, fuel 123%, machinery 44% — fuel flagged over budget the same day it happened, not at month-end close.
• ~110 hours/month released from manual data entry toward analysis.
• Year-one return of 2.6x – 7.6x, and 6.7x – 19x in steady state. The conservative end counts released hours only; the upper end counts recovered VAT and avoided overdrafts, which the case flags as assumptions to validate in the first month rather than as booked.
• Phased rollout on the systems already in use: weeks 1–4 transparency with zero friction in the field; weeks 5–8 zero-friction capture; weeks 9–12 preventive control; month 6+ the read-only layer starts watching the margin. Each phase delivers a result before asking for the next change of routine.