Catching invoice problems before payment, not after

A control that runs after payment isn't a control. It's reporting on something you can no longer prevent.

The situation

A fintech company operating multiple real estate buildings across Asia had the usual problem with payables at scale: by the time an issue surfaced, the invoice had typically already been approved and paid.

Duplicate payments, and delays on payments that genuinely couldn't slip — rent, utilities — were being found in review rather than prevented.

What we built

We developed a tool that flags variances the moment an invoice is entered into the system — before approval, and before payment.

  • Potential duplicate payments flagged at the point of entry
  • Delays in critical rental payments surfaced automatically
  • Delays in utility payments surfaced on the same basis
  • Integrated with the company's real estate operations system, so the finance check runs against operational reality rather than the ledger alone

Why it matters

Moving the check to the point of entry costs almost nothing to enforce and removes an entire category of recurring error. The same check applied after payment produces a list of things to chase.

This is the kind of work that's easy to justify but rarely gets built, because it sits between the finance team and the operations system and nobody owns the gap.

Other things we've built.

Have a problem that looks like this?

Most finance problems are architecture problems wearing a different hat. Tell us what's breaking and we'll tell you what we'd do.

Talk to Us