The hard parts, already running
Duplicate protection, clean recovery from an interrupted run, variance tracking and a per-user audit trail are already running in production on a system we built and operate, where a wrong number is an audit finding. Every automation vendor can describe the run that works. This page is the other one, and what we have built to meet it.
- Built in production under statutory financial reporting
- Idempotency by default, not on request
- Behaviour on failure agreed before anything is built
- Monitored runs, so you are not the one who finds it broke
Most of what goes wrong with an automation is not the automation. It is everything around it: a token that expired, an API that changed shape, a run that stopped halfway, an event that arrived twice. These get decided before we build, not discovered afterwards.
The record below comes from a financial system, which is the hard case rather than a narrow one. Somewhere a wrong number is an audit finding, duplicate protection and clean recovery are not features anyone gets to defer. The same mechanisms are what keep a ticket queue from double-assigning and an access review from finding a leaver still provisioned.
- 09:14:02extractok
- 09:14:02matchok
- 09:14:03post → ledger502 upstream unavailable
- 09:14:08post → ledgerretry 1
- 09:14:23post → ledgerok
- 09:14:23reconciled1 posted · 0 duplicates
recovered without anyone being told
- 11:02:40extractok
- 11:02:40matchno purchase order found
- 11:02:40postheld
- 11:02:41escalatedto a person, document attached
- 11:02:41ledgerunchanged
stopped rather than guessed
Illustrations, not measurements. How many times a run retries, how long it waits and the point at which a person is told are agreed for your process before anything is built - the one thing that is never configurable is posting a guess.
When this happens
The same event arrives twice
A duplicate is worse than a miss, because it acts. A second invoice reaches a supplier, a second provisioning run grants access twice, a replayed webhook raises the same ticket for two engineers.
Already built
Idempotent sync with duplicate protection on reconnect, so a device that comes back online after an outage cannot replay what it already sent.
When this happens
A run half-finished
The dangerous failure is not the one that stops. It is the one that wrote three records out of five and reported success - half a month end, half an onboarding, half a report.
Already built
Local-first capture with clean recovery after interrupted or crashed sessions, so an interrupted run resumes from what actually landed rather than from the beginning.
When this happens
A third party is unreachable mid-run
Someone else deciding to deploy should not become your outage.
Already built
Local-first capture and sync-on-return, built for sites where the connection is not a given. The same pattern covers an unreachable third party: the work is held and replayed rather than lost, and the retry policy is set per integration.
When this happens
A wrong figure reaches the ledger
In accounting an error is not an inconvenience, it is a restatement and possibly an audit finding.
Already built
Per-transaction references, reporting with persistent counters, and automated variance tracking that flags a discrepancy the moment it appears rather than at period end.
When this happens
Money moves the wrong way
Refunds and partial payments are where financial logic quietly goes wrong, and where nobody checks until a customer complains.
Already built
Proportional refund allocation back across mixed tenders on a single transaction, in production.
When this happens
Nobody knows who changed what
The first question in any investigation, audit or access review, and the one most systems cannot answer.
Already built
Every action logged and tied to the user behind it, with role-based limits on who can do what.
When this happens
Our data mixed with somebody else’s
A multi-tenant system that leaks between tenants is not a bug, it is a breach.
Already built
Complete data isolation per tenant, with encryption in transit and at rest.
What is not on this page: an uptime figure, a response-time guarantee, or a number for how often any of it has saved somebody. Those need either a measurement we have not taken or a promise we cannot keep across other people’s APIs, and this site would rather be short than wrong.
Questions we get asked
Why does this page exist instead of a list of client logos?
Because it is the question a finance team actually asks, and almost nobody answers it. Logos tell you somebody signed; this tells you what happens on the day something upstream changes. We would rather be judged on the second.
What exactly do you mean by "already built"?
Each capability on this page runs in production on a multi-tenant transactional platform we built and operate, under statutory fiscal reporting requirements. We do not name it here because this site is not here to sell it, and because it may sit beside systems our clients already run. Ask and we will tell you what it is.
Do you guarantee uptime?
No, and be careful of anyone who does for work that depends on third-party APIs. What we commit to is that we find out before you do, that failures are visible rather than silent, and that recovery is designed in rather than improvised on the day.
What happens if we stop paying for Managed Automation?
The automation keeps running. What stops is the monitoring, the alerting and the maintenance - so when an API changes or a credential expires, you find out the way you would have before: from somebody downstream.
Tell us what you need built.
Describe the process you repeat and we will tell you whether it is worth automating - including when it is not. A fixed price for the build, quoted before anything starts.