Belgium E-Reporting 2028: What SAP Teams Can Build Before the Technical Rules Are Final

Belgium has moved its 2028 e-reporting plan from coalition policy into a preliminary legislative proposal. On 18 July 2026, the Council of Ministers approved a preliminary draft law for near-real-time reporting of selected mandatory invoice data by both the supplier and the customer.

What can SAP teams build before Belgium publishes the final e-reporting rules?

SAP teams can build the scope register, canonical invoice data layer, document correlation, reconciliation workflow, retry controls, evidence archive and test harness now. They should not hard-code a final authority schema, deadline, process identifier or acknowledgement model until Belgium enacts the law and publishes the implementing rules.

Article scope: This article covers Belgium’s proposed 2028 dual-sided e-reporting model and what SAP teams can prepare before final rules. For the current 2026 structured B2B e-invoicing and Peppol baseline, use the Belgium B2B E-Invoicing for SAP guide.

The legal status is important

The confirmed fact is narrow but consequential. Belgium’s Council of Ministers approved a preliminary draft law to amend the VAT Code. The proposal introduces near-real-time electronic reporting of certain mandatory invoice data by both the supplier or service provider and the counterparty. It would also remove the annual customer listing obligation for taxpayers covered by the new reporting requirement.

This is not yet an enacted operating mandate. The preliminary draft was sent to the Belgian Data Protection Authority and the Council of State for advice. The official e-invoicing portal continues to describe 2028 as the target timing and states that the measure still requires transposition into Belgian law.

Why dual-sided reporting changes the SAP design

A supplier-side reporting model can often be designed as an extension of outbound billing. A dual-sided model also requires the customer to report or confirm data from the same economic transaction. That brings SAP SD, FI-AR, FI-AP, purchasing, invoice management, master data and external Peppol services into one control boundary.

The two reports must be reconcilable even when the parties use different internal document numbers, posting dates or correction processes. A technically accepted outbound report does not prove that the counterparty’s representation matches it. SAP teams therefore need a persistent correlation model that links the commercial invoice, structured Peppol document, SAP accounting documents, authority submission and every later correction.

Build the stable layers now

1. Define reporting scope as versioned requirements

Create a scope register by Belgian VAT registration, company code, establishment, transaction type, document direction and source process. Mark the e-reporting requirement as proposed until the law is enacted. Every later legal or technical publication should create a controlled requirement version rather than silently replacing the earlier interpretation.

2. Separate the SAP data model from the authority payload

Build a canonical invoice record that preserves source fields and their provenance across SD billing, FI invoices, credit notes, self-billing and inbound AP. Keep the Belgian reporting mapping outside the extraction layer. This allows the final schema and business rules to change without rewriting every SAP source connector.

3. Create durable document correlation

Assign a stable internal correlation identifier and retain supplier and customer VAT identifiers, invoice number, issue date, currency, totals, references, Peppol message identifiers and SAP document keys. The correlation must survive rejection, resubmission, cancellation, crediting and reposting.

4. Design reconciliation as a workflow

Model the states needed to distinguish source creation, Peppol exchange, reporting eligibility, submission, technical acknowledgement, business acceptance, mismatch, correction and closure. Do not collapse these into a single success flag. Each exception needs an owner, due date, decision and verified outcome.

5. Make retries idempotent

Near-real-time obligations create pressure to retry quickly, but an uncertain response must not create a duplicate report. Store request hashes, transmission identifiers, timestamps and returned statuses. Before replay, determine whether the previous attempt failed before acceptance or whether the authority may already hold the report.

6. Preserve evidence independently of dashboards

Retain the source snapshot, mapped payload, validation result, transmitted message, acknowledgement, correction chain and final status. A monitor screen helps operations, but it is not the audit evidence. The underlying records must remain exportable and traceable to the SAP source.

7. Prepare a rule-driven test harness

Create test scenarios for invoices, credit notes, corrected documents, self-billing, mixed VAT rates, exemptions, rounding, foreign currency and identifier failures. Keep expected results configurable. When Belgium publishes schemas and validation rules, the team can add rule-specific assertions without rebuilding the test framework.

Keep these decisions blocked

Some architecture choices cannot be responsibly finalized yet. Do not promise a production mapping, fixed delivery estimate or legal coverage based only on the preliminary draft. The final design should remain conditional on enacted scope, implementing decrees, Peppol specifications, authority acknowledgements, correction rules, testing arrangements and penalties.

The 2027 transfer of the Belgian Peppol Authority to FPS Finance is strategically relevant because Peppol will support both e-invoicing and future reporting. It does not, by itself, confirm the final five-corner topology, process identifiers or provider obligations.

Translate the proposal into controlled SAP work

DRC Sprint can record Belgium’s proposed requirements separately from confirmed obligations, collect the SAP evidence needed for each company code, keep unresolved architecture decisions blocked and convert confirmed gaps into owned implementation work. This lets a team prepare reusable foundations without presenting assumptions as compliance.

Primary sources

• Belgian Council of Ministers: introduction of electronic reporting of invoice data, 18 July 2026
• Belgian federal e-invoicing portal: general questions about e-reporting
• Belgian federal announcement: FPS Finance to become the Belgian Peppol Authority in 2027
• Belgian federal e-invoicing portal: structured B2B invoices compulsory since 2026

Verification date: 12 August 2026. Recheck the enacted law and technical publications before approving production scope or mappings.