What is VAT Return Preparation and Submission (EU / UK)?

VAT Return Preparation and Submission (EU / UK) is an ERP workflow guide for Tax & Regulatory Compliance. It focuses on VAT Compliance.

What should a finance team verify before implementation?

Given posted sales and purchase transactions for a VAT period with output VAT and input VAT at line level; when the Tax Manager generates the VAT return and submits via HMRC MTD API with valid OAuth 2.0 token; then all nine VAT return boxes are computed from digitally-linked transaction data, submission receipt is stored, and the period obligation status updates to FULFILLED; (negative) when the OAuth token is expired or invalid then the submission is rejected with a 401 error and the system triggers a token refresh before retrying.

VAT Return Preparation and Submission (EU / UK)

VAT Compliance is where ERP discipline either begins or breaks.

VAT Return Preparation and Submission (EU / UK) looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.

The expected business outcome is specific: VAT return filed on time through the correct channel with mathematically correct output/input reconciliation.

The control flow a finance team actually needs.

Workflow map for this ERP process, including exception handling and audit evidence.

Step 1

VAT Codes Applied At Transaction Line...

Step 2

Partial Exemption Pro-Rata Calculation...

Step 3

MTD Submission Via HMRC API With OAuth 2.0

Step 4

Submission Receipt Stored

Step 5

VAT Return Period Aligned To...

The ERP surface involved.

Module

VAT Compliance

Actors

Tax Manager, Accounting Manager, HMRC / EU National Tax Authority Portal

Tier

Tier 2

Finance area

Tax & Regulatory Compliance

Region lens

US and UK finance teams

Publication date

April 16, 2026

VAT codes (standard, reduced, zero, exempt, outside-scope, reverse-charge) applied at transaction line level; partial exemption pro-rata calculation per HMRC / jurisdiction rules; MTD submission via HMRC API with OAuth 2.0; submission receipt stored; VAT return period aligned to company-configured cycle (monthly, quarterly, annual); reverse-charge lines split into output and input VAT boxes automatically; amendment process supported.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Control area	Requirement	Acceptance proof
Control 1	VAT codes (standard, reduced, zero, exempt, outside-scope, reverse-charge) applied at transaction line level	Given posted sales and purchase transactions for a VAT period with output VAT and input VAT at line level
Control 2	partial exemption pro-rata calculation per HMRC / jurisdiction rules	when the Tax Manager generates the VAT return and submits via HMRC MTD API with valid OAuth 2.0 token
Control 3	MTD submission via HMRC API with OAuth 2.0	then all nine VAT return boxes are computed from digitally-linked transaction data, submission receipt is stored, and the period obligation status updates to FULFILLED
Control 4	submission receipt stored	negative) when the OAuth token is expired or invalid then the submission is rejected with a 401 error and the system triggers a token refresh before retrying.
Control 5	VAT return period aligned to company-configured cycle (monthly, quarterly, annual	VAT return filed on time through the correct channel with mathematically correct output/input reconciliation.
Control 6	reverse-charge lines split into output and input VAT boxes automatically	VAT return filed on time through the correct channel with mathematically correct output/input reconciliation.

Audit evidence is a chain, not a folder.

Evidence layer	What should be preserved
Business event	At the end of each VAT period, the ERP compiles output VAT (collected on sales) and input VAT (paid on purchases eligible for recovery) from posted transactions. The system applies partial exemption rules where applicable, computes net VAT payable or reclaimable, and generates the return in the required format (e.g., UK VAT100, German Umsatzsteuervoranmeldung, French CA3). For Making Tax Digital (MTD) jurisdictions, the return is submitted via the HMRC API using the company's OAuth-authorized connection. The system records the submission receipt and triggers payment or refund workflow.
Control rules	VAT codes (standard, reduced, zero, exempt, outside-scope, reverse-charge) applied at transaction line level; partial exemption pro-rata calculation per HMRC / jurisdiction rules; MTD submission via HMRC API with OAuth 2.0; submission receipt stored; VAT return period aligned to company-configured cycle (monthly, quarterly, annual); reverse-charge lines split into output and input VAT boxes automatically; amendment process supported.
Acceptance proof	Given posted sales and purchase transactions for a VAT period with output VAT and input VAT at line level; when the Tax Manager generates the VAT return and submits via HMRC MTD API with valid OAuth 2.0 token; then all nine VAT return boxes are computed from digitally-linked transaction data, submission receipt is stored, and the period obligation status updates to FULFILLED; (negative) when the OAuth token is expired or invalid then the submission is rejected with a 401 error and the system triggers a token refresh before retrying.
Data record	vat_return { id: string, entity_id: string, period_start: date, period_end: date, box1_output_vat_minor: int64, box4_input_vat_minor: int64, box5_net_vat_minor: int64, currency_code: char(3), submission_receipt: string, partial_exemption_ratio: decimal, status: enum(DRAFT,SUBMITTED,FULFILLED,AMENDED), external_id: string }; vat_line { transaction_id, vat_code: enum(STANDARD,REDUCED,ZERO,EXEMPT,OUTSIDE_SCOPE,REVERSE_CHARGE), output_vat_minor: int64, input_vat_minor: int64, currency_code: char(3) }; (reference, product may differ).
System event	`POST /v1/vat-returns/prepare { entity_id, period_start, period_end } -> 201 { id, boxes[1..9] }; POST /v1/vat-returns/{id}/submit -> 200 { submission_receipt, obligation_status }; GET /v1/vat-returns/{id}; emits vat_return.submitted, vat_return.fulfilled events; idempotent via external_id.`
Lifecycle state	`DRAFT -> SUBMITTED -> FULFILLED; terminal AMENDED; guard: box totals derived only from digitally-linked transactions, no manual override permitted; reverse-charge lines must populate both output and input VAT boxes.`

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

Reference data model

`vat_return` { id: string, entity_id: string, period_start: date, period_end: date, box1_output_vat_minor: int64, box4_input_vat_minor: int64, box5_net_vat_minor: int64, currency_code: char(3), submission_receipt: string, partial_exemption_ratio: decimal, status: enum(DRAFT,SUBMITTED,FULFILLED,AMENDED), external_id: string }; `vat_line` { transaction_id, vat_code: enum(STANDARD,REDUCED,ZERO,EXEMPT,OUTSIDE_SCOPE,REVERSE_CHARGE), output_vat_minor: int64, input_vat_minor: int64, currency_code: char(3) }; (reference, product may differ).

API and events

`POST /v1/vat-returns/prepare` { entity_id, period_start, period_end } -> 201 { id, boxes[1..9] }; `POST /v1/vat-returns/{id}/submit` -> 200 { submission_receipt, obligation_status }; `GET /v1/vat-returns/{id}`; emits `vat_return.submitted`, `vat_return.fulfilled` events; idempotent via `external_id`.

State transitions

`DRAFT -> SUBMITTED -> FULFILLED`; terminal `AMENDED`; guard: box totals derived only from digitally-linked transactions, no manual override permitted; reverse-charge lines must populate both output and input VAT boxes.

Common implementation traps.

Treating the workflow as data entry

If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.

Hiding exception logic

Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.

Posting without recovery design

Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.

Skipping evidence design

A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.

Where Rivane fits.

Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.

References and source basis.

These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.

Back to ERP use cases