How should financial software handle a mistake or a wrong number?

By correcting it, not by editing it. A mistaken entry should be fixed with a reversing entry and a new correct one, both visible and both attributed to whoever made them, rather than by changing the original value in place. This sounds like bureaucratic caution and it is actually what makes reporting trustworthy: if somebody can quietly change a figure from six weeks ago, then last month's report no longer says what it said last month, and no number in the system can be relied on twice. The same principle explains why balances are better derived from recorded events than stored in a field and updated. When the events are the source of truth, a disputed total can be explained by showing the entries that produced it, and a correction leaves a visible trail instead of erasing the previous state. The practical test to apply to any vendor is simple: ask how a wrong entry from last quarter gets fixed. If the answer involves editing a record, ask what happens to the report that was already sent.

What does an audit trail need to include in financial software?

At minimum: who did what, when they did it, which record it affected, and the value before and after the change. Just as important is who can read it. An audit trail is only useful if the finance lead can look something up without an engineer running a database query, which is what separates it from ordinary application logging. Logs exist to help developers debug; an audit trail is evidence a business can produce for an auditor, a lender, an insurer or an unhappy customer, so it needs to be a named feature with a screen rather than a file somewhere on a server. Two details are commonly missed. Approvals and permission changes belong in the trail alongside the transactions, because who was allowed to do something is often the question being asked. And it is expensive to add retrospectively, since a trail switched on in year two says nothing at all about year one, which is exactly the period somebody will eventually ask about.

Why is software that handles money more expensive to build than ordinary software?

Because the cost sits in the parts a demo never shows. Two products can have the same number of screens and be very different builds once one of them is the system of record. The reliability bar is higher, since a value that is wrong for an hour causes a payment, a chase or a filing that has to be undone. The data model is stricter, because totals have to be reconstructible from recorded events rather than stored and overwritten. Money has to be typed and rounded to a stated rule rather than treated as an ordinary decimal, quantities carry units whose conversion factors are business data with a history, and the dates split into when something happened, when it was recorded and which accounting period it belongs to. On top of that sit the features nobody asks for in the first meeting and everybody needs by month three: reconciliation against bank statements and supplier invoices, period closing, approval rules, an audit trail and a clean export for the accountant. None of it is exotic engineering, but all of it is real work, which is why the cheaper of two quotes is often cheaper for exactly these reasons.

Building Financial Software: What Changes When Your App Keeps the Books

TL;DR: Most software can be wrong for an hour and nobody notices. Software that keeps the books cannot, because the moment a business starts quoting your screens in a meeting, your application is no longer a tool, it is the record. Four things change when that happens: you have to store what happened rather than what the total is, corrections become entries instead of edits, reconciliation with the outside world turns into a real part of the product, and the audit trail becomes a feature with an owner. Here is what actually makes financial software different to build, where the expensive mistakes hide, and what to ask before commissioning one.

The moment your software becomes the system of record

There is a specific day on every project like this, and it arrives before anyone plans for it. Somebody in a meeting says a number, somebody else asks where it came from, and the answer is the name of your software. From that day the product is judged on whether the number is right, whether it is current, and whether anyone can explain how it got there.

That is a higher bar than it sounds, and it is not the same bar as moving money. Taking payments is a solved problem with good providers, and sitting in the middle of somebody else's transaction has its own concerns, which we cover in the guide to marketplace builds. Being the book of record is a different job: you are where a business finds out what it is owed, what it owes and what it earned, and those answers are only useful if they are trusted.

The tell is simple. If a wrong value on a screen would cause somebody to make a payment, chase a customer, file a return or close a period incorrectly, you are building financial software whatever the product is called. Plenty of products cross that line without noticing: inventory systems that carry value, billing engines, commission tools, anything replacing a spreadsheet somebody invoiced from.

Fyuel, the accounting platform we built for the fuel trade, was designed for that position from the start. It brings customers, suppliers, tankers, ledgers, banks and reports into one clean, real-time system, so a fuel business stops stitching that picture together by hand. The consolidation is the value, and also the obligation: once you are the single place, being current is the product.

Record what happened, not what the total is

The most expensive shortcut in financial software is storing a balance in a field and updating it. It looks efficient, and it means that the moment two things happen at once, a job runs twice, or someone corrects an entry, you have a number nobody can defend and no way to find out when it went wrong, because the previous value is gone.

The alternative is unglamorous and it is what durable financial systems have always done: record the events, and derive the totals. A payment received, an invoice issued, a load delivered, an adjustment applied. Each is a fact with a timestamp and an author, written once and never modified. The balance is then calculated from those facts, either on demand or into a cached figure that can be rebuilt from scratch at any time. If a total is disputed, you can show the entries that produced it, which is the difference between an answer and an opinion.

The rule that follows from this is the one clients push back on most, and it is worth holding: you do not edit history, you correct it. A mistaken entry is fixed by a reversing entry and a new correct one, both visible, both attributed. That is not bureaucratic caution, it is what makes last month's report still say what it said last month. A system where somebody can quietly change a figure from six weeks ago is a system where no report can be trusted twice.

The same discipline shows up outside finance. In Elemental Universe, the multiplayer card game we built where the cards are genuine NFTs deployed on-chain, ownership is a matter of record rather than a value someone can overwrite.

Reconciliation is the product, not an edge case

The numbers inside your software will disagree with the numbers outside it, routinely, and that is normal rather than a bug. The bank statement lands with a fee you did not know about. The supplier invoice covers a delivery you recorded on a different day. The stock count comes back short.

Software that assumes agreement produces a support ticket every time reality intrudes. Software that expects disagreement makes it somebody's ten-minute job. So the design has to treat the unhappy path as a first-class feature: an import of the outside record, an automatic match on the obvious items, a queue for the rest, and a way to explain a difference and write the correcting entry from that same screen.

Whoever does this work is usually not an engineer, which is the point. Reconciliation is where the business proves to itself that the system is telling the truth, so it needs a designed screen rather than a report that ends in someone opening a spreadsheet. It is also where a vertical build earns its money, because the matching rules are specific to the trade: what counts as the same delivery, what tolerance is acceptable, who is right when there is a conflict. That is the "live and correct" argument from vertical SaaS build versus buy, applied where it is most visible.

Money, units and dates: the three quiet sources of financial bugs

Three ordinary looking things cause most defects in financial systems, and all three are cheap to get right at the start and painful to retrofit.

Money is not a decimal number. It is an amount plus a currency, stored in the smallest unit and handled with a type that does not drift. Floating point arithmetic on currency is the classic source of the penny that never balances. Rounding needs a stated rule and place too: rounding each line and rounding the total give different answers, both defensible, and the system has to pick one and apply it everywhere, including when something is credited back.

Quantities carry units, and conversion is a business rule. Anyone building for a physical trade meets this immediately. Fuel is measured, moved and billed in units that convert, and a conversion factor is business data with a history, not a constant someone types into a formula. The same applies to weights, hours, packs and cases. When the unit lives only in the column heading, the mistake arrives eventually.

Dates are at least three different dates. When something happened, when it was recorded, and which accounting period it belongs to are separate facts, and treating them as one is what makes month-end painful. Keep them distinct and the two features people ask for late become straightforward: closing a period so nothing can be booked into it afterwards, and reporting on what the books said at a point in time rather than only what they say now.

None of this is exotic engineering, but it is part of why a system of record costs more than a product with the same number of screens. The reliability bar is doing the work, not the feature list, which is the same point we make about what an MVP actually costs.

Who can change it, and how you prove what happened

In financial software, permissions are part of the domain, not a settings page bolted on at the end.

The questions are concrete. Who can create an entry, who can approve one, and may those be the same person above a threshold. Who can void or reverse. Who can reopen a closed period, and does that leave a mark. Who can see margin, payroll or supplier pricing, given that plenty of people need the operational screens without the commercial ones. Deciding this before the build is easier than discovering during a rollout that everyone shares a login.

The audit trail is the other half, and it deserves to be a named feature rather than a log file. A useful one records who did what, when, to which record, with the value before and after, and the finance lead can read it without an engineer running a query. That last part is what separates an audit trail from logging: logs are for debugging, an audit trail is evidence you can produce for an auditor, a lender or an unhappy customer. It is also expensive to fix backwards, since a trail switched on in year two says nothing about year one.

Two things travel with it. Export has to be a real feature, in a format an accountant actually uses, because your software sits inside a process that does not end at your login screen. And the data needs a proven restore, not a backup setting that is switched on. As we put it in software ownership and handover, the application can be rebuilt but the ledger cannot, which makes an untested backup a genuine business risk.

Buyer checklist

If you are commissioning software that will hold your numbers, these seven questions separate a considered build from an optimistic one.

Are totals derived from recorded events, or stored and updated? If the answer is stored, ask how a disputed figure gets explained.
How does a mistake get fixed? Listen for corrections and reversals, not edits.
What happens when the bank, the supplier or the stock count disagrees with us? There should be a screen, not an apology.
How are money, units and dates typed? Ask specifically about rounding rules and about the difference between transaction date and accounting period.
Can we close a period, and can we report on what the books said back then?
Who can approve what, and can one person do both sides of a transaction?
Can our accountant get the data out today, and has a restore been tested on real data?

Financial software is not harder because the features are complicated. It is harder because being wrong has consequences ordinary software does not carry, and almost all of that cost sits in the parts a demo never shows, which is worth knowing before you compare two quotes. And if you are replacing a system the business still runs on, the modernization sequence matters as much as the build, since the numbers have to keep working every day of the transition.

Null Studio builds systems businesses actually run on, from real-time accounting platforms to the operational software underneath them. Book a demo and we will tell you honestly what your product needs to get right before it becomes the place your numbers live. See our work: Fyuel, Geonode's Repocket SDKs, Raqts and more, shipped in days, not months.