An auditor’s first question about a number is not whether it is right. It is where it came from. “Right” can only be settled afterwards, once you know the source, who entered it, and what it ought to agree with somewhere else.
From 2012 to 2014 I was a senior audit manager for SAP systems at a firm of chartered accountants, working on SAP implementations and financial reporting. I had been writing software since 1999, and since 2014 I have done AI and automation full-time. The habits came with me, because audit is a discipline for distrusting numbers politely, and software produces numbers all day.
The trail
Every entry in a set of books should lead back to something: a document, a person, a date. In SAP a posted document has a number and an author, and you do not quietly edit the past; you post a reversal on top of it. An auditor can follow that trail from a figure in the accounts back to the voucher behind it.
Software usually lacks this. A table updated in place can tell you a customer’s credit limit, but not who changed it, when, or what it was before. An automation that runs at night and logs nothing can tell you nothing on the morning it goes wrong. That is why logging and failure alerts are part of every automation I build, not an extra. Where the past matters, keep history instead of overwriting it. It pays for itself the first time someone asks where a number came from.
Sampling
Nobody checks every transaction. You choose a sample, and the skill is in the choosing: some items at random, so the sample stands for the whole, and some on purpose. The large amounts, the suspiciously round ones, the entries posted on the last day of the year. The odd items are where errors live.
Most test suites skip that second half. Hand-made test data is tidy by construction: every amount positive, every date comfortably mid-month. Real data has credit notes, zero-value invoices, a customer name with an apostrophe and a transaction dated 31 March at one minute to midnight. That is why the AI work I offer starts with a working prototype on a sample of the client’s own data, before the full build is priced. Real records find what tidy fixtures never will.
Reconciliation
A bank reconciliation takes two records of the same money, kept by two parties, and makes them agree. When they do not, every difference is explained: a cheque not yet presented, a charge not yet booked. What you never do is plug the gap with a balancing figure and move on, because the gap is information.
Anything that moves or transforms data deserves the same treatment, against a second source it did not produce. A migration should end with counts and totals compared by account and by month, because one grand total can hide two errors that cancel out. A nightly import should count what arrived and what landed. The engineering version of the plug is the tweak that makes a failing test pass without anyone understanding why it failed, and it is as dangerous in code as in accounts.
Materiality
Auditors do not chase every rupee. A misstatement is material when it is large enough, or sensitive enough, to change the decision of someone relying on the accounts. The second half matters: a small error in a tax figure can be material where a larger one in stationery is not.
A slow or messy system has dozens of things worth fixing, and fixing them in the order you notice them is how months disappear. So an audit and rescue from me ends in a written assessment with the fixes ranked by cost and payoff: work down the list and stop when what remains no longer matters. Keep the sensitivity test too. A rare bug in an invoice total deserves more attention than a frequent one in a tooltip.
Independence
An auditor cannot audit work they prepared. It is not a question of honesty. The person who made a mistake is the one least able to see it, because they read what they meant rather than what they wrote.
This is the habit I work hardest at, because I work as one engineer, without reviewers down the corridor. So independence has to be borrowed. The client’s own people, checking output against figures they already know, are the most independent reviewers there are. The handover (code, credentials and a plain-English runbook) is written for a stranger. And the assessment from an audit and rescue says it outright: hand it to anyone, including a different engineer.
The opinion
An audit report does not say the accounts are correct. It says they give a true and fair view, which is a more modest promise and a more honest one. It is the right promise for software too. Nobody can promise a system has no bugs. You can promise that its numbers can be traced, that it was tested on real data, that its output reconciles with an independent source, that its worst problems were fixed first, and that someone other than its author has checked it. That is a promise a client can hold me to, and one any auditor would recognise.
