In short. A typical first statutory audit for a Series A or Series B UK fintech turns on six topics in order of weight: revenue recognition under IFRS 15, safeguarding compliance evidence, classification of customer monies, going concern with one or two equity rounds in the assessment period, share-based payments, and intercompany or related-party debt. Done well, the file becomes the template for years two through five. Done badly, it becomes the document the next auditor remediates.

1. The starting position

The typical UK fintech facing its first statutory audit is somewhere between two and five years old, has raised an equity round that crosses the small-company audit-exemption thresholds under section 477 of the Companies Act 2006, or holds an FCA authorisation (typically as an Electronic Money Institution, Payment Institution, or under the small registered EMI regime) that requires audited accounts under regulatory rules.

The trigger for the audit is usually one of three: a Series B equity round where the new lead requires audited accounts, an FCA application for a permission upgrade, or a counterparty contract that conditions on audited statements. Whichever the trigger, the company arrives at the audit with three structural disadvantages: no prior audit file to inherit, financial reporting capacity built for management reporting rather than statutory reporting, and an internal-controls environment built for product velocity rather than financial-statement integrity.

None of these are pathologies. They are normal at this stage. The audit firm’s job is to deliver the opinion without imposing the controls overlay of a listed entity. The company’s job is to use the first audit to build the file foundation it will need for the next four to five years of audits, not to optimise for minimum disruption in year one.

2. Revenue recognition under IFRS 15: the largest workpaper

Almost every fintech has a revenue recognition workpaper that is larger than the rest of the audit combined. There are three reasons.

First, fintech revenue models are heterogeneous within a single company. A typical fintech earns transaction fees, interchange share, subscription revenue, foreign-exchange spread, interest income, and sometimes a residual that defies categorisation. Each of these has a different performance-obligation analysis under IFRS 15 paragraphs 22 to 30, a different transfer-of-control determination, and a different measurement approach.

Second, the IFRS 15 analysis is rarely retrospective. The audit team typically arrives to find that the contracts have not been individually evaluated against the IFRS 15 five-step framework, and the revenue recognition policy is a generic statement copied from a precedent file. The five-step analysis — identify the contract, identify performance obligations, determine the transaction price, allocate, recognise — needs to be performed live for the audit.

Third, the technical accounting answers are often counterintuitive to a finance team trained on management reporting. Whether the company is a principal or an agent on a payment transaction can change the gross-versus-net revenue presentation by orders of magnitude. Whether a customer acquisition cost is a contract cost capitalised under IFRS 15 paragraph 91 or an expense recognised in period is a frequent first-year discussion.

A defensible IFRS 15 workpaper in a fintech audit contains: a revenue stream inventory; a five-step memorandum per material revenue stream; a principal-versus-agent analysis per stream where intermediaries are involved; a transaction-price-variable-consideration analysis where applicable; and a disclosure draft mapped to the workpaper. Total length is typically twenty to thirty pages. It is the largest single workpaper in the file.

3. Safeguarding: the regulatory-statutory interaction

For FCA-authorised EMIs and PIs, customer funds are subject to safeguarding obligations under the Electronic Money Regulations 2011 and the Payment Services Regulations 2017. The safeguarding regime requires firms to segregate relevant funds either by holding them in a designated safeguarding account or by covering them with an insurance policy or comparable guarantee.

The safeguarding obligation is regulatory, not statutory. But the audit cannot avoid it. Three intersection points matter.

Annual safeguarding audit. Many EMI authorisations require an annual safeguarding audit report addressed to the firm and the FCA, in the form set out in FCA finalised guidance. This is a separate engagement from the statutory audit but typically runs alongside it. Whether the same firm performs both or different firms perform each is a planning decision worth having in the first month.

Customer-monies classification on the balance sheet. Safeguarded funds are typically held by the firm in a fiduciary capacity. The accounting classification depends on the legal structure of the safeguarding arrangement: pure trust, statutory trust, or contractual segregation. The accounting answer drives whether the customer monies sit on the balance sheet as a liability with a matching asset, or are off-balance-sheet entirely. Getting this right in year one prevents a restatement in year two.

Reconciliation evidence. Safeguarding rules require daily or sub-daily reconciliation of safeguarded balances. The audit needs evidence that this reconciliation has occurred throughout the period, not just at year end. The control evidence here is operational rather than financial-reporting evidence, but it underpins the going-concern conclusion as well as the balance-sheet classification.

4. Going concern in the equity-funded context

Going concern for a fintech is materially different from going concern for a mature regulated entity, for one structural reason: the going-concern period frequently contains an equity round that has not yet closed at the date of the auditor’s opinion.

The standard analytical questions — does the entity have cash, is the cash forecast plausible, what is the stress — map awkwardly to a company whose continued existence depends on an event that is probable but not certain. Three approaches that work, and one that does not.

The approach that does not work: treating the next equity round as a mitigating action with high plausibility. This is an inspection finding waiting to happen. A planned but unsigned equity round is not a mitigating action; it is a contingency.

The approach that does work: assessing going concern on two parallel bases. Base case assumes the next equity round closes within the forecast period at the term-sheet conditions. Downside case assumes the round does not close, and assesses whether the entity can operate within available cash and facility headroom for the assessment period. The audit conclusion holds if the downside case is survivable, not because the base case is plausible. This framing places the going-concern conclusion on the cash already in the bank rather than on the cash expected to arrive.

For companies where the downside case is not survivable, the auditor faces a material uncertainty conclusion. ISA 570 paragraph 22 requires this to be disclosed in a Material Uncertainty Related to Going Concern paragraph in the auditor’s report. The disclosure does not modify the opinion; it draws attention. Many first-audit fintechs end up with this paragraph in year one and lose it in year two when the next round has closed. This is not a failure of the audit; it is the audit doing what it is supposed to.

5. Share-based payments under FRS 102 or IFRS 2

Almost every fintech has an employee option scheme. The accounting for these schemes, under FRS 102 Section 26 or IFRS 2 if the entity reports under IFRS, is one of the most consistent first-audit findings.

The recurring issues are mechanical rather than conceptual. The grants are documented in board minutes but not in a register that links each grant to the valuation, the vesting conditions, and the expense recognition profile. The valuations have been performed by a previous adviser using a Black-Scholes model whose inputs are not retained. The vesting profile in the option agreement does not match the expense recognition pattern in the management accounts. The dilutive impact on earnings per share, where required, has not been calculated.

The fix is operationally simple: a single share-based payment register, owned by the controller, with one row per grant, columns for grant date, recipient, number of options, exercise price, vesting conditions, valuation methodology, valuation inputs, total fair value, recognition profile, and current period expense. The register is the workpaper. Tied to it: the underlying board minutes, the option agreements, and the valuation memoranda.

This is a workpaper that, once built, requires only marginal updates each year. It is exactly the kind of artefact whose absence in year one creates four cycles of follow-up questions, and whose presence in year one closes the topic permanently.

6. Intercompany and related-party items

Fintechs at Series A or B often have surprisingly complex intercompany structures: a UK regulated entity, a holding company, a US sales subsidiary, sometimes a separate technology entity. Intercompany loans, recharges, and service-fee arrangements are routine.

Three audit considerations apply.

First, intercompany balances need to reconcile bilaterally. This is mechanical but frequently fails because each entity has booked the balance independently and never reconciled to the counterparty. The audit identifies the difference; the audit team and the controller spend a day resolving it.

Second, intercompany loans need a documented basis: interest rate, repayment terms, denomination. The recurring failure is that the loan was raised informally and has never been documented. Retrospective documentation is acceptable; absence of documentation is not.

Third, related-party disclosure under FRS 102 Section 33 or IAS 24 requires identification of all related parties, including directors and their close family. The recurring failure is the close-family-member declarations have not been collected from directors. The audit cannot conclude on completeness without them. The fix is a director declaration form, signed annually, retained as a permanent file.

7. The five-week timetable

A typical first audit for a Series B fintech runs for five to seven weeks of elapsed time. The phases:

  • Week one: planning, scoping, risk assessment, materiality, walkthroughs of key processes.
  • Weeks two to three: substantive testing across revenue, cash and safeguarding, payroll and share-based payments, intercompany, going concern, opening balances.
  • Week four: technical accounting positions, particularly IFRS 15 conclusions and any contested classifications. Drafting of disclosure narratives.
  • Week five: completion procedures, going-concern conclusion, subsequent-events review, management representations, audit committee or board presentation, signing.

The fastest version of this timetable I have run is four weeks for a relatively simple PI. The longest is nine weeks for a fintech with a recently completed acquisition and a partially-implemented new general ledger. Five weeks is the modal length and the right planning assumption.

8. What the company should expect to come away with

A first audit done well leaves the company with five durable artefacts that compound through subsequent cycles: an IFRS 15 revenue policy memorandum that does not need to be redone next year; a share-based payment register that updates rather than rebuilds; a related-party process and director declaration cycle that becomes routine; a documented going-concern file structure that survives both equity rounds and regulatory events; and a working-paper file that the next year’s audit team can inherit without rewriting.

The cost of building these correctly in year one is roughly fifteen to twenty percent more senior time than the minimum-viable audit. The compound benefit over years two through five is roughly forty percent less senior time per audit. The math, in other words, favours doing the work properly the first time.

9. Closing observation

A first statutory audit is not a compliance event. It is the construction of the financial-statement infrastructure that a company will operate under for the rest of its independent existence. The companies that approach it that way come out of year one with a file structure that compounds. The companies that approach it as a tick-box come out of year one with a relationship to be repaired and a file to be rewritten in year two.

The decision is usually made in week one of the engagement, often without anyone realising the decision is being made.

— DK Buledi, November 2025