Most software treats a VAT return as a document you assemble. AIONA treats it as a number your ledger already knows. The nine boxes of an MTD VAT return are computed from posted journals and nothing else - no side spreadsheet, no manual adjustment layered on at the end, no gap between what the books say and what the return claims. Run the computation twice over the same posted journals and you get the same return, to the penny, both times.
That matters because the person who signs the return carries the liability. This page covers how the VAT position is built, what happens at period close, where our HMRC recognition application stands - stated plainly, because you should not have to discover it during onboarding - and how payroll RTI and the CT600 come off the same ledger.
A 9-box you can take apart
Every figure in the return derives deterministically from journals a human has signed off. Nothing posts to the ledger without that sign-off: the AI reads each document and scores its own confidence, low confidence blocks posting outright, and any override needs a written reason recorded in a tamper-evident audit log. By the time a journal contributes to Box 1, it has already been reviewed.
Because the return is computed rather than compiled, it is traceable in both directions:
- Every box breaks down into the journals that produced it.
- Every journal links to its source document, so a query on Box 4 ends at an invoice, not at a shrug.
- The position is recomputable at any moment. Ask for the VAT position on the 14th and you get the ledger's answer as of the 14th, not a stale estimate.
Closed means closed
When you close a VAT period, AIONA takes an immutable snapshot of the return. The ledger itself is immutable too: corrections happen by reversal, never by editing history. If a late purchase invoice surfaces in March for a period closed in February, the correction posts as a visible reversal in the open period and the February snapshot stays exactly as it stood at close. Nothing rewrites the past quietly. Two years on, you can recompute the period from its journals and reconcile the result against the snapshot line by line.
You can see what that output looks like now: a specimen 9-box report from a demonstration book is in the specimens section.
Where we stand with HMRC
Plainly: AIONA's VAT submission has been built and sandbox-tested against HMRC's published specification, including the fraud-prevention headers HMRC requires from submitting software. Our application for software recognition is in progress. It is not complete, and we will not imply otherwise.
Until it completes, you file VAT and RTI through your existing route - your current filing tool or HMRC's own services - using the computed, snapshotted figures AIONA gives you. The value today is the numbers being right and provably so; the submission click follows if recognition is granted, and progress is posted on the changelog as it happens.
Payroll RTI, prepared as bookkeeping
Payroll in AIONA is RTI preparation from the ledger outwards. You preview the FPS and EPS before anything touches the books, and the wages, PAYE and NI figures post as balanced journals into the same ledger the VAT return reads. There is no separate payroll silo whose totals get re-keyed at month-end, and because control accounts are locked from day one, the PAYE and NI liabilities cannot be posted around. The same rule applies here: preparation in AIONA, submission through your existing route until recognition completes.
CT600 from the ledger, not from re-keying
The CT600 computation prefills from the profit and loss the posted journals produce, with capital allowances calculated from the fixed-asset register rather than from a memory of what was bought. It is prepared, not submitted: you review the computation, apply judgement where judgement is required, and file through your existing corporation tax route. What you do not do is re-type a year of figures into a separate tax product and hope nothing moved in between.
Month-end that earns the close
The returns above are only as good as the close discipline beneath them, so period close is a workflow, not a date on a calendar. Depreciation, prepayments and recurring journals run at month-end, and pre-close checks look for the things that quietly poison a return, from unreconciled items to journals still sitting in draft. When close shows green, it means the ledger confirms it now - a live check against the books, not a box someone ticked three weeks ago.
If you are weighing this against a workflow where software posts first and you review later, we have written up the difference in review-first versus silent automation.
What getting it wrong costs
The penalty-points regime makes repeated late submissions steadily more expensive, and inaccuracies carry their own penalties on top - and the reputational cost lands on the practice before the financial one lands on the client. To put numbers on your exposure, use the VAT penalty calculator; to plan the year ahead, the MTD VAT 2026 practice checklist walks through what to have in place for each client.
Pricing is £24 per client per month, falling to £19 from your 26th client and £15 from your 76th, with unlimited users and AI included. Your own practice's books and your first client are free, and every book exports in full to CSV or Excel at any time, with no exit fee - details in the pricing section. Sceptical is the right starting posture for filing software; talk to us and bring the awkward questions.