Finance workflows where the approval changes the numbers, not just the status
Approval chains, audit trails and payment chasing built into the system the books live in, with an honest note on month-end, which none of our case studies covers.
Finance automation is two jobs that get sold as one. The first is moving a document through approval without anyone chasing it. The second is making two sets of numbers agree. Both fail in the same way: the status says one thing and the total says another, and someone finds out at the close.
Our evidence is two custom systems. On a trading group's ERP, approvals deliberately gate revenue, purchases and outstanding totals, and a field-level audit log records every change. On an independent school group's ERP, fees, payments, expenses and payroll feed one accounting layer, and fee reminders go out over WhatsApp as a scheduled action. Both are built, not configured on a finance product.
What we cannot show is also worth stating. No case study on this site is a month-end close, and no published case study covers an integration with a named accounting package. This page is organised around what the two builds do show, and the month-end section says so in as many words.
Approvals that change the numbers, and chasing that leaves a record
- 01
A status that is not decorative
On the trading ERP, invoices move draft, pending review, approved, unpaid, partial, paid. Drafts and invoices still under review are deliberately excluded from revenue, purchases and outstanding totals on both the lists and the dashboard, because nothing is owed until an invoice is approved. The failure this prevents is the one where a total includes things no one has signed off.
- 02
A human on the step that writes
Where an invoice is captured by photograph and read by a vision model, nothing is written on the model's reading alone. The extraction is presented for review and only the person's confirmation creates the purchase invoice and moves stock quantities, item cost prices and the supplier balance. The AI invoice processing page covers that pipeline in full.
- 03
Permissions that decide who can approve
Roles on the trading build are a grid of eighteen modules against five actions, editable per role and overridable per person. Navigation hides what a person cannot view, routes redirect, and the write layer checks before touching the database, while a database trigger stops anyone changing their own role or permissions. Who may approve is a permission rather than a button that happens to be hidden, and approval authority would be set the same way, designed with you.
- 04
A record of every change
Every write stamps the acting user and appends a field-level diff to an append-only table that staff can select from and insert into but never update or delete. When a figure is wrong you can establish who changed it, when, and what it was before, which was exactly what the legacy ledger could not do.
- 05
Chasing that is a process, not a notebook
On the school build, fee collection depended on someone remembering to chase, and the record of who had been chased lived in a notebook. Reminders now go out over WhatsApp from templates, so chasing is a scheduled action with a record rather than an act of memory.
Reconciliation is mostly about how many places a number lives
The trading group's two records of a supplier invoice, one in the ledger and one in a stock spreadsheet, disagreed constantly because a person re-keyed the same paper invoice into both. No reconciliation process fixes that cheaply. Removing the second copy does.
The school group's answer was the same in a different form. Students, fee invoices, payments, expenses, employees and payslips feed a single accounting layer, so a fee receipt and a salary payment land in the same books and the reports reconcile without a spreadsheet in between.
Where you are keeping two systems, our cost article is the framing we use. The cost of agreement depends on who owns what:
| Shape | What has to be built | Effect |
|---|---|---|
| One owner, data flows outward | A push per destination, with idempotency so a retry does not duplicate | Roughly linear |
| Two systems, each field owned by one | A field-by-field mapping with a direction, and read-only enforcement on the other side | Adds a mapping per field |
| Two systems, both edited, no owner | Conflict rules, a matching key, a merge policy, a reconciliation report | Multiplies, and keeps costing |
Migration is the other reconciliation. When the trading group's old books were decoded, the recovered history was reconciled against paper records, with one document verified to the line.
Month-end: what we can and cannot say
What we can say is narrower. A close tends to be slower when its inputs are not clean: invoices still unapproved, a stock record that disagrees with the ledger, a figure nobody can trace. The approval gating, single ledger and audit log above bear on inputs of that kind, but we have not measured their effect on any close.
The useful exercise, which costs nothing, is the one from our cost article. Not what normally happens at the close, but in the last one, how many items did somebody touch by hand, and why? The answers are the exception list, and the exception list is most of any estimate. A finance team that cannot answer is describing the process as designed rather than as run.
What moves the estimate for a finance process
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and neither case study states a price or a duration, so the range is not attributed to them. Our build-versus-buy article says a focused automation or integration is typically two to four weeks and a full application, such as an ERP module set, eight to twelve; treat those as typical ranges, not a quote. What moves the estimate is the exception list (in your last close, what did somebody touch by hand, and why), how many systems believe they own the same data, and whether the rules need a database underneath.
Rules that need memory, a once-only guarantee, per-user visibility or a permanent audit trail belong in a database, and the cost article calls crossing that line usually the step change in an estimate. Finance is where it comes up most, and the append-only log and permission layers above are why it is a build rather than a configuration.
When finance workflow automation should stay on a platform, or stay manual
If your accounting product's own approval routing does what you need, use it; building next to it creates a reconciliation. And approvals on a workflow platform are perfectly good until the rule needs memory, a guarantee or proof. This can only happen once, this depends on what happened before, we must be able to show what it did months later: those are the tells that the rule belongs in a database. A platform's run log will not outlive its retention window, and an audit trail has to.
Leave rare exceptions manual at first. A case arising twice a year seldom repays the build, and it adds a path that has to keep working. We also do not do the accounting: tax treatment, statutory reporting and anything that depends on a regulator's rules are outside what our case studies show, and we would not claim compliance work we cannot evidence.
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
- A regional trading & distribution groupAn ERP with AI invoice capture and an audit trail that holdsNot a finance-workflow engagement in itself: it is a full ERP, and the finance workflow is part of it. The approval states that gate revenue, purchases and outstanding totals, the confirmed capture of supplier invoices and the append-only audit log described above all come from this build, so read it for those pieces.Case study
- An independent school groupSchool management ERP with permissions enforced per branchAlso a full ERP rather than a finance-workflow engagement. The single accounting layer behind fees, payments, expenses and payroll, and the scheduled WhatsApp fee reminders, come from this build.Case study
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot a finance build. It is a business-day SLA clock against a real holiday calendar that survives reallocation and escalates on its own, which is the mechanism you would reach for to escalate an approval nobody has actioned. We have not applied it to a finance process.Case study
The disciplines behind it
Related reading
Finance workflow automation, specifically
Yes, and the evidence is the trading ERP: invoices move through draft, pending review, approved, unpaid, partial and paid, with drafts and anything under review excluded from revenue, purchases and outstanding totals. The approval changes the numbers, not only a label. Permissions are checked in the write layer and not only in the screens, a database trigger stops anyone escalating their own role, and every change is recorded with a field-level diff.
No published case study of ours covers those products. Where an accounting package has an API or an import route, the pipeline in front of it is independent of where the confirmed data lands, so it is feasible to scope, but we would do that against your actual package. Where there is no usable route, there is usually still a supportable one through exports.
We cannot honestly give you a number. None of our case studies is a month-end close. What we can say is that the inputs to a close are cleaner when approvals gate the totals, a single ledger removes the copy that disagrees, and every figure is traceable. The first step is counting what your team touched by hand last month and why.
A platform is fine until the rules need memory, a guarantee or a proof. If an approval can only happen once, depends on prior state, or must be provable months later, those belong in a database, because a platform run log will not outlive its retention window. For a simple, low-risk, linear approval a platform is cheaper and we would say so.
Not without a trace. Whether an approved invoice can be edited at all is a permission we would design with you; what the trading build guarantees is that every change is recorded. Every write goes through one data-access layer that appends a field-level diff to an append-only table, so the trail cannot be rewritten even by the application. Deleting sets a timestamp rather than destroying the row, only an administrator can purge, and the audit entry outlives the record.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no