The pitch versus the problem
Every few years, blockchain gets re-pitched as the answer to fraud, reconciliation, and trust in finance software. Most of the time, the actual problem doesn't need a distributed ledger — it needs a database with proper constraints, an audit log, and someone who checks the reconciliation report.
Where blockchain-style thinking genuinely earns its place is narrower: any place where you need to prove, after the fact, that a record was not altered — not just that it wasn't, but that it couldn't have been without leaving evidence.
Invoice integrity as a concrete example
GST filing in India is a good example of where this matters. Fake or backdated invoices are a real, well-documented problem, and the fix isn't more paperwork — it's making the invoice record itself hard to quietly edit after issuance.
That's a tamper-evidence problem, not a blockchain-marketing problem. It can be solved with cryptographic hashing and append-only ledgers without needing a public chain, a token, or any of the infrastructure that usually comes attached to the word 'blockchain'.
Regulatory reality in India
Compliance systems here have to work with GSTN, existing accounting workflows, and auditors who need a report they can read — not a wallet address they need to explain to a tax officer. Any tamper-evidence layer has to be invisible to the end user and legible to the regulator.
That's the actual engineering constraint: cryptographic integrity underneath, completely ordinary accounting software on top.
Our position
We use the underlying ideas from blockchain — hashing, append-only structures, verifiable audit trails — where a system genuinely needs to prove it wasn't tampered with. We don't reach for distributed ledgers as a default, and we're upfront with clients when a simpler, boring database solves their problem just as well.