If you run Oracle Fusion in the UK, validating it for HMRC Making Tax Digital (MTD) for VAT comes down to proving three things: that your VAT records are kept digitally, that the data flows from source transaction to VAT return through unbroken digital links with no manual re-keying, and that the return is submitted through HMRC-recognised software over HMRC's API. This post is a practical guide to what to test in Oracle Fusion so you can demonstrate that end to end — it is not legal or tax advice, and you should confirm the current rules directly with HMRC guidance before you rely on any test plan.
MTD is a records-and-process obligation as much as a filing obligation. It is entirely possible to produce a numerically correct VAT return and still fall short of MTD because a figure was copied by hand into a spreadsheet along the way, or because the submission path was not an HMRC-recognised digital channel. That is why testing has to follow the data, not just check the totals.
What Making Tax Digital actually requires
At a general level, MTD for VAT sets out a handful of principles that your Oracle Fusion configuration and its downstream tooling need to honour. Describe them accurately, and the test scope almost writes itself:
- Digital record-keeping. The VAT records that feed your return must be held in a digital form, not reconstructed manually at period end.
- Digital links. Where data moves between programs or systems on the way to the return, the transfer must be a digital link. Once a figure is captured digitally, re-typing or copy-pasting it by hand breaks the chain.
- Recognised software and API submission. The return is submitted to HMRC through software that is compatible with HMRC's MTD service, using HMRC's API rather than a manual keying of boxes into a portal.
- An auditable trail. You should be able to show, for any figure on the return, the digital path back to the underlying transactions.
Notice what this list does not include: specific rates, thresholds, penalty amounts, filing deadlines, or the exact fields in HMRC's API payload. Those details do exist, and they change. Rather than hard-code them into your understanding here, treat them as parameters to look up against current HMRC guidance and to pin down with your tax function. Your test plan should reference "the applicable rate" and "the current submission window," and let the authoritative source fill in the value.
Where Oracle Fusion sits in the MTD chain
In most UK deployments, Oracle Fusion is the system of record: transactions in Payables, Receivables, and the tax engine generate the VAT amounts, and Fusion's tax reporting produces the figures that make up the return. The submission to HMRC then happens either through a Fusion capability or, very commonly, through a bridging or middleware layer that holds HMRC recognition and talks to the API. Confirm which pattern applies to your estate with Oracle and your integration partner — the boundary between "Fusion" and "the recognised submission software" is exactly where digital links are most likely to break.
That handoff is the crux of MTD testing. A VAT figure can be computed perfectly inside Fusion and still fail MTD if someone exports it to a spreadsheet, adjusts a cell by hand, and uploads the result. Your job in testing is to walk the whole path — source document to submitted return — and confirm there is no point where a human types a number that a machine should have carried across.
What to test in Oracle Fusion for MTD
The table below is a starting checklist. It is deliberately framed as "what to test in Oracle Fusion," not as a statement of the rules themselves. Adapt the acceptance criteria to your own registration, group structure, and the current HMRC requirements.
| Test area | What you are validating | Evidence of a pass |
|---|---|---|
| VAT calculation | The tax engine applies the correct treatment and rate to representative transactions across your VAT scenarios (standard, reduced, zero-rated, exempt, reverse charge, partial exemption where relevant). | Computed VAT matches an independently derived expected value for each scenario; edge cases and rounding behave as intended. |
| Digital-link chain | Data moves from source transaction through tax reporting to the submission layer entirely via digital links, with no manual re-keying, copy-paste, or hand adjustment at any hop. | Each transfer point is a system-to-system link; any spreadsheet in the path is connected by formula or import, not manual typing. |
| Return figures (box mapping) | Each VAT return box is populated from the correct underlying data and reconciles to the tax subledger and the transactions behind it. | Every box value traces to source records; totals reconcile with no unexplained differences. |
| Submission / API handoff | The return is transmitted to HMRC through recognised software over the API, and the figures received match the figures approved in Fusion. | Submitted payload equals the reviewed return; HMRC acknowledgement or receipt is captured and stored. |
| Error handling | Rejections, timeouts, authentication failures, and validation errors from the submission channel are surfaced, not silently swallowed, and the process is safely retryable. | Failed submissions raise a clear, actionable error; no partial or duplicate submissions occur on retry. |
| Audit trail | For any submitted figure you can reconstruct the digital path back to source, including who reviewed and approved the return. | A retained, tamper-evident record links return, approval, submission, and acknowledgement to the underlying transactions. |
Testing VAT calculation
Start with the numbers, because if the calculation is wrong nothing downstream matters. Build a scenario set that exercises your real VAT profile rather than a single happy-path invoice: the rates and treatments you actually use, transactions that cross rate boundaries, credit notes and reversals, foreign-currency documents, and any partial-exemption or reverse-charge cases that apply to your business. For each, derive the expected VAT independently and compare it against what Fusion's tax engine produces. Pay particular attention to rounding, because small rounding differences compound at the return level. Our guidance on Oracle tax testing goes deeper on constructing scenario coverage that stands up to scrutiny.
Testing the digital-link chain end to end
This is the test that is most specific to MTD and the one teams most often under-scope. Map every hop the VAT data takes from the originating transaction to the point of submission, and confirm each hop is a genuine digital link. If a spreadsheet appears anywhere in the chain — a common reality for adjustments, group consolidation, or partial-exemption calculations — it is not automatically a problem, but the way data enters and leaves it must be by digital link, not by someone reading a number off one screen and typing it into another. Walk the chain deliberately and try to break it: the failure you are hunting for is the manual re-key that a tidy demo would never reveal.
Testing return figures and the submission handoff
Reconcile each box on the return back to the tax subledger and the transactions that feed it, then confirm that the figures approved inside Fusion are exactly the figures that leave through the recognised submission software. The value that HMRC receives must equal the value your team signed off. Test the handoff itself, not just the report: submit into a test or sandbox environment where one is available, and verify the acknowledgement comes back and is stored against the period.
Testing error handling and the audit trail
MTD submissions travel over an API, and APIs fail — authentication lapses, the service times out, a validation rule rejects the payload. Test those paths on purpose. A rejected submission must produce a clear error and a safe retry, never a silent failure or an accidental duplicate. Finally, confirm the audit trail: for any figure on a submitted return you should be able to reconstruct the digital path back to source transactions, together with the review and approval that authorised it. That evidence is what turns "we think we are compliant" into something you can actually show.
MTD compliance is a controls problem too
Getting the figures right is necessary but not sufficient. Who can change tax configuration, adjust a return, or trigger a submission is itself a compliance question, and it overlaps directly with your access-controls testing. Preparing an Oracle Fusion estate for MTD sits alongside broader work on segregation of duties for HMRC Making Tax Digital — that page focuses on who is allowed to do what around the VAT process, where this post focuses on validating that the numbers and the digital chain are correct. Read them together: a clean calculation submitted by someone who should not have had the access to change it is still a finding. Our wider work on Oracle Fusion segregation of duties sets out how to test those access boundaries.
If you operate across other jurisdictions with digital-reporting regimes, the same "walk the chain, confirm the handoff, prove the audit trail" discipline transfers. Teams working in the Gulf face a comparable challenge, and our note on Oracle Fusion GCC compliance testing shows how the pattern applies to ZATCA, WPS, and PACI. In every case the caution is the same: describe the framework accurately, but confirm the specific thresholds, deadlines, and file formats against the current authority guidance rather than a blog.
Keep testing after every Oracle update
MTD compliance is not a one-time certification. Oracle's quarterly updates can touch the tax engine, tax reporting, or the integration that carries data to your submission software, and a change to any of those can break a digital link or shift a calculation without anyone intending it to. The practical answer is to keep an MTD regression pack — calculation scenarios, the end-to-end digital-link walk, box reconciliation, submission and error handling — and re-run it against each update before you accept it. Building that repeatable coverage is exactly what a purpose-built Oracle ERP testing tool is for.
How SyntraFlow helps
SyntraFlow can be configured to turn the checklist above into a repeatable test suite for your Oracle Fusion VAT process — exercising VAT calculation across your real scenario set, walking the digital-link chain end to end to surface any manual re-keying, reconciling return figures, and confirming the submission handoff and its error paths behave as expected. It helps organisations assess whether an Oracle update has quietly changed any of that, and it can connect release intelligence with test planning so an MTD regression pack runs before each quarterly update lands. SyntraFlow does not file your VAT return or replace HMRC-recognised submission software, and it is not a substitute for professional tax advice — it is the testing engine that gives you evidence your Oracle Fusion configuration still does what MTD requires. Always confirm the current rules with HMRC guidance and your tax advisers.