Finance Operations
Every invoice line traces to proven work. Every payment to an invoice.
A deployed agent that raises invoices only from approved work records, matches incoming payments back to them, and puts the short-pay in front of a person as a number rather than a hunch.
The situation
Two shapes, and a person in between.
A services business bills for people's time. The invoice is only as good as the record of hours behind it, and the cash is only as good as the match between what was paid and what was billed. In most finance functions those three things live in three places: a filing system, an invoicing tool, and a bank feed. A person reconciles them at month end, by eye, from exports.
That person is where the errors hide. An invoice raised from an unapproved week. A payment applied to the wrong invoice because the amounts were close. A short payment nobody noticed because the customer paid something.
The failure mode
Why the invoicing tool cannot fix this on its own.
Invoicing tools start at the invoice. They have no idea whether the hours on it were ever approved, and they treat a payment as settled the moment a number roughly matches. The reconciliation that matters — did the work happen, was it billed correctly, did the money arrive in full — sits upstream and downstream of the tool at once.
Automating the invoice alone moves the error earlier. It does not remove it.
Architecture
Invoices are derived from records, never typed.
-
01
Every line is proven by a record
An invoice line exists only because an approved activity record exists for that person, that week, at that rate. The line carries the record it came from. Change the record and the line changes; there is no second copy to drift.
-
02
Nothing is raised on an open period
A month that is still receiving records cannot be invoiced. The system holds the invoice until the period closes and says so, rather than raising an estimate and correcting it later.
-
03
Three-way match: work, invoice, bank
Each invoice is reconciled in three steps and shown as three states. Approved hours agree with the lines. The lines agree with the amount raised. The bank feed shows the amount received against it. Any step that does not close is visible as an open circle, not buried in a total.
-
04
A short payment is a number, not a status
When a customer pays part of an invoice, the system does not mark it paid or unpaid. It shows what arrived, what is still open, and how many days remain inside terms — the exact thing the person chasing it needs to say.
-
05
Reminders are sent by rule and counted
An invoice past terms is chased on a schedule, and the count of reminders sent sits next to the invoice. A person steps in when the count says the schedule has stopped working.
-
06
The ledger is mirrored, not re-entered
Customers, invoices, payments, and service items are mirrored into the accounting system from the same records. A sync that cannot complete — a service item with no mapping — stops and asks a person, and says why.
In operation
What it looks like running.
- Open receivable, past-terms amount, and weighted days-to-pay visible at a glance, measured against the bank feed rather than against the invoice list
- Each invoice opens to its lines, and each line to the approved record it was billed from
- A part-paid invoice shows the shortfall as an amount and the days left inside terms
- A month still receiving records is shown as not yet billable, with what has arrived so far
- Ageing buckets and per-customer exposure derived from the same reconciled state
- The accounting mirror reports what is in step, what is behind, and where it stopped to ask
On screen
The system, as the operator sees it.
Downstream
The accounting system receives facts, not typing.
Once an invoice is derived from proven records and matched to a bank line, mirroring it into the accounting system is an ordinary sync of ordinary data. The failure mode of most integrations — two systems disagreeing about a number that was typed twice — cannot occur when there was only ever one number.
The sync is built to stop. A record it cannot map is a question for a person, raised with the reason, not a silent skip.
What transfers
The match is the product.
None of this needed a model to decide anything. Which record proves which line is a lookup. Whether a payment matches an invoice is arithmetic with a tolerance. The intelligence in the system is refusing to let those be typed.
Where a model does help is upstream — reading the unstructured records the invoice is built from — and that problem is the subject of the HR operations case study. This system is what becomes possible once that upstream is trustworthy.