Design for the day your automation is wrong

Twelve years of my career have gone into systems where a wrong number has consequences. Insurance data at Rippling. Ad pipelines at Hotstar and Udaan. Payments at Hike, more than a million dollars a day. Most recently, quick commerce at Amazon.

I left Amazon to build Rivane, an AI-native accounting platform. People ask why an engineer would walk into finance. The honest answer is that finance is where everything I learned about reliable systems matters most.

The part software never did

When I started looking closely at accounting software, what struck me first was how much of it is genuinely good. Bookkeeping became accessible to millions of small businesses. Consolidation got solved at a scale most people never see. These were hard problems, and they were solved well.

What none of it could do, at the time it was built, was the judgment. Deciding which two transactions are the same one. Deciding what an unexplained variance means. Deciding whether a difference is worth chasing.

That was left to people, because there was no other option. Finance teams have carried it brilliantly, by hand, ever since.

Picture a group with ten entities across three countries. Every month it exports trial balances into a spreadsheet, converts currencies, eliminates the transactions between its own companies, and reconciles by eye. It's careful, skilled work. It also takes ten to fifteen days, every single month, from people who could be solving harder problems.

That layer is now buildable. Not by anyone alone; this will take many companies. But it's a good time to be entering.

Averages lie

Coming from payments and product risk, I'm skeptical of averages.

In risk systems, errors don't have equal costs. Blocking a legitimate payment and missing a fraudulent one are both mistakes, but they create very different consequences. Accounting has the same asymmetry:

• Misclassifying a small software expense is not the same as producing an unsupported revenue entry.
• Drafting a journal is not the same as posting it.
• Missing evidence is not the same as conflicting evidence.

So a single accuracy number tells you very little. A model can score well on an accounting benchmark and still be unsafe in production. Another can score lower and still create real value, if it reliably stops on the cases it shouldn't touch.

That's why I believe the most important prediction an accounting AI makes isn't the account code. It's whether it should act at all.

Draw the action boundary in the open

For every workflow, I want to know four things: how much work the system attempts, how often its accepted actions are correct, whether its confidence matches its real reliability, and what it costs when it's wrong. Those measurements should decide the boundary:

• Low-risk, well-supported work proceeds automatically.
• Medium-risk work is drafted, with its evidence attached.
• Material or unusual entries require approval.
• Conflicting inputs make the system abstain.

As models improve, that boundary can move. But the policy should always stay explicit, written down, where a controller can read it.

Design for the day it's wrong

Here's the principle I keep returning to: an AI accounting system should be designed for the day its automation is wrong.

That isn't pessimism. It's systems engineering. A reliable system isn't only fast when its inputs are clean. It's recoverable when a dependency fails, a policy changes, or an edge case slips through.

So for every reconciliation, classification or journal Rivane proposes, we keep the source evidence, the policy and model version, the confidence and the exception reason, every approval and edit, and the exact impact on the ledger. That lets you make three moves when something goes wrong:

1. Contain. Find every affected transaction and stop further incorrect postings.
2. Replay. Re-run them with corrected inputs, policies or models.
3. Compare. See the accounting difference before any reversal or correcting entry is posted.

An audit trail tells you what happened. Recoverability lets you fix it, while keeping the link between the original entry and its correction.

From the standards up

We didn't wrap someone else's ledger. We rebuilt it, so the software can make the calls a person makes today, with every one of them logged, reasoned and reversible. In accounting, an answer you can't audit isn't an answer. The standard we hold ourselves to is that a person can always see exactly why, and undo it.

We also learned accounting from the standards up, and the accountants who taught us were remarkably generous with their time. Much of what we've built is simply what they told us should exist.

We're starting with multi-entity groups in the Gulf: too complex for entry-level bookkeeping tools, too small for the heavyweight enterprise suites. There, multi-entity is the norm rather than the exception, and new tax rules are moving a lot of groups off spreadsheets at once.

One question keeps us honest, and it's the one I'd ask of any accounting AI, ours included: would a finance team actually trust this with their books? Being 95% right is often not enough. If we can earn that trust in the most critical part of the back office, we'll have earned the right to build much more.

If you lead finance at a multi-entity group, or advise companies that do, I'd love to talk over tea, coffee, breakfast or lunch. Get in touch through Rivane.