Does SAP DRC replace OpenText VIM?

No — the two sit on different layers. DRC is one possible compliance and transmission layer: receive, validate, report. VIM is the processing layer: check, approve, post, handle exceptions. The transmission route can just as well be a plain e-mail — the processing layer is needed either way, otherwise the work moves back into accounting.

Do we need SAP DRC — or does it work without?

For a purely German invoice intake it works without. Germany follows the post-audit model: no platform is prescribed, exchange by e-mail is compliant, and VIM processes the incoming XRechnung or ZUGFeRD file directly. DRC — or a Peppol provider, or existing middleware — becomes relevant when Peppol is mandated, foreign clearance systems are involved, or statutory reporting has to be handled. What makes sense for you depends on countries, volumes and your SAP roadmap, not on a product decision made upfront.

Do we still need OCR and capture?

As long as suppliers send paper or plain PDFs: yes. The XML share is growing, but the transition takes years. The good news: in VIM both channels merge into the same process — you are not running two separate worlds.

Do we need separate processes for XML and paper?

No, and that is the real advantage. VIM ships an inbound handler that processes paper, images, pure XML and hybrid formats such as ZUGFeRD in the same line — each with the steps that document actually needs. After that, every invoice is the same document under the same business rules, whatever channel it came from. What it takes is clean channel control, not a second solution.

How does a human review an XML invoice?

In raw form, they do not — XML is made for machines. VIM therefore generates a readable PDF view out of the mapped fields, laid out like an invoice and labelled in the reviewer’s language. The approver sees a document, the machine processes the data — and what gets archived is still the XML, not the view.

What about invoices from abroad — KSeF, FatturaPA and the like?

Every country has its own model, from central clearing platforms to reporting obligations. There are several ways to connect: SAP DRC covers many of these countries and is updated continuously by SAP, and specialised providers and middleware solutions do the same. Which countries are relevant for you at all is a question of your vendor list — exactly what the first conversation is for.

How much time do we have?

In Germany you must be able to receive e-invoices already today. The obligation to issue them arrives in stages from 2027 — and a clean intake setup in VIM, with a transmission route such as DRC where needed, requires lead time for concept, customizing and testing. Planning in 2026 means being on time; starting in 2027 means being under pressure.

How does Johannes Auer IT Consulting support this?

We analyse your current VIM setup, design the target picture for e-invoice intake — with or without DRC — and implement it in VIM: customizing, intake channels, business rules, testing. Team training included on request.

Is a PDF invoice still an e-invoice?

No. Since 2025, Germany only recognises as an e-invoice what is issued, transmitted and received in a structured electronic format per EN 16931. A plain PDF is an “other invoice” — still permitted during the transition, but on its way out.

What is the difference between XRechnung and ZUGFeRD?

XRechnung is pure XML without a visual file — built for fully automated processing. ZUGFeRD is a hybrid: a PDF/A-3 with embedded XML that people can read and machines can process. Both are EN 16931 compliant from the appropriate profile upwards; in both cases, processing runs on the XML.

Does the German issuing mandate apply to small businesses?

Small businesses under § 19 UStG are exempt from the obligation to issue e-invoices. They must still be able to receive them, though — the receiving mandate knows no such exception.

Do we need a Peppol access point?

Only if you want or need to send or receive via the Peppol network — for example in Belgian B2B or towards public authorities in many EU countries. Important for SAP shops: the access point alone is not enough. Peppol delivers the UBL inside a UN/CEFACT envelope, and VIM only processes plain UBL. SAP DRC does the unpacking — without DRC it has to be built as a custom extension. For German B2B exchange by e-mail, Peppol is not a prerequisite at all.

How does an e-invoice have to be archived?

Audit-proof and GoBD-compliant — and it is the structured data set itself that matters. The XML must be archived, not just a printout or the PDF view. An archive that only stores the invoice image does not meet the requirement.

Consulting

SAP DRC, OpenText VIM and the e-invoice.Who does what?

The e-invoicing mandates are here, and so are the tools — what is often unclear is who plays which role. This page separates the three layers cleanly: the format, the transmission route (in Germany plain e-mail is enough; SAP DRC is one option among several) and the processing in OpenText VIM. Compliant, without sacrificing your proven approval process.

Request a first conversation Book 30-min call

The next key dates

1 Sep 2026France
receiving for all, issuing for large and mid-sized companies
1 Oct 2026Greece
second stage: all remaining businesses
1 Jan 2027Germany
issuing mandate above €800,000 prior-year turnover
1 Jan 2028Germany
issuing mandate for all businesses

See all countries and deadlines

Why this is on the table right now

01
Germany
Since January 2025, companies must be able to receive e-invoices; the obligation to issue them follows in stages from 2027. Paper and plain PDF invoices are being phased out.
02
Europe and beyond
ViDA brings digital reporting requirements for cross-border transactions. Italy, Poland, France, Romania: every country builds its own clearing or reporting model — whoever buys internationally needs an answer per country.
03
Inside the company
Invoice intake becomes a compliance question: who receives which format, who validates, who reports — and what happens to the well-rehearsed review and approval process in accounts payable?

Country overview

Who mandates what, and when?

Every country builds its own model — from clearance through Peppol to plain reporting duties, often in several stages. The interactive overview shows every date, filterable by year, with a link to each authority.

29: dates
21: countries
12: already in force

Open the interactive country overview

already mandatory
still to come

Three layers, three roles

01
The format — what arrives
An e-invoice is not a PDF but structured XML: XRechnung, ZUGFeRD (hybrid), Peppol BIS or a country format like FatturaPA. Machine-readable, validatable, reportable — and the reason intake is changing at all.
02
The transmission route — how it arrives
Germany prescribes no procedure: an XRechnung by e-mail is as valid as one via Peppol — except that e-mail only needs a mailbox, while Peppol requires an access point and additionally brings the UN/CEFACT envelope that VIM cannot unpack. For the Peppol route, SAP DRC is therefore the standard path. As long as you receive purely German invoices by e-mail, you do not need it.
03
The processing — OpenText VIM
VIM turns the received document into a checked, approved, posted one: business rules, role determination, exceptions, approval workflow. Exactly what no transmission route does — however modern it is.

How invoice intake runs in VIM

Intake

Route into SAP

E-mailXRechnung, ZUGFeRDdirect
PeppolBelgian B2B, authoritiesaccess point + SAP DRC
Clearance countriesItaly, Poland, RomaniaSAP DRC
Paper & PDFunstructured documentsscan or e-mail

One process

OpenText VIM

business rules · role determination · exceptions · approval

Result

Posted in SAP

archived audit-proof, reportable

01
Receive
By e-mail the XRechnung lands straight in the invoice mailbox and VIM reads the XML directly. With ZUGFeRD, intake first separates the XML part out of the PDF; what gets processed from then on is that XML, not the image. From the Peppol network nothing arrives directly: an access point and the unpacking of the UN/CEFACT envelope sit in between, in practice via SAP DRC. Paper and plain PDFs arrive by scan or e-mail and are read out. All paths merge into the same process.
02
Create in VIM
The e-invoice becomes a DP document — no OCR, no manual validation: the data is already structured in the XML.
03
Check & workflow
Business rules, duplicate check, approvals — the proven VIM process stays the same, regardless of the intake channel.
04
Post & prove
Posted in SAP, archived audit-proof, reportable — and the KPIs show how much faster the XML channel is compared to paper.

The formats: XRechnung, ZUGFeRD, Peppol & co.

01
XRechnung
The German standard maintained by KoSIT: pure XML per EN 16931, as UBL or UN/CEFACT CII. Mandatory in B2G since 2020 — addressed via the Leitweg-ID — and the format of choice for structured B2B exchange.
02
ZUGFeRD / Factur-X
The hybrid format: a PDF/A-3 with embedded XML, technically identical to the French Factur-X. From the EN 16931 profile upwards a fully valid e-invoice — legally, the XML part counts, not the PDF view.
03
Peppol BIS Billing 3.0
The network format: UBL XML exchanged via certified access points in the four-corner model. The B2B standard in Belgium, the route to public authorities in many countries — and a permitted transmission channel in Germany.
04
EN 16931
The norm behind everything: the European semantic data model of the e-invoice. Whether XRechnung, ZUGFeRD or Peppol BIS — an e-invoice is whatever maps back to this norm.
05
Country formats
FatturaPA in Italy, the FA schema in Poland’s KSeF, e-Factura in Romania: clearance countries define their own formats and platforms. Whoever buys or sells there needs a channel per country.
06
EDI (EDIFACT)
The legacy channel: established EDI connections may continue in Germany for a transition period — but their content must become EN 16931 compliant by the end of 2027. Nobody has to switch them off; everybody has to convert them.

Put simply: a letterbox just for e-invoices — delivered system to system.

Peppol, explained simply

Put simply, Peppol is a digital letterbox just for e-invoices — an alternative to receiving them by e-mail. Every company has a unique address in it, to which suppliers deliver their invoices directly.

Behind it sits a network established across Europe for the automated exchange of electronic documents between businesses and with public authorities. The letterbox is provided by a certified access point — comparable to an e-mail provider, only with proof of delivery and a central participant directory.

For German B2B exchange, Peppol is not mandatory — e-mail is enough. In Belgian B2B and towards public authorities in many EU countries, however, there is no way around it. How a Peppol invoice then reaches SAP VIM is what the intake routes just below show.

Four routes into the system — one process in VIM

The transmission route is a decision, not a requirement. For German invoice intake the first route is enough in most companies — the others are added when countries, networks or reporting duties call for them.

01
E-mail with XRechnung or ZUGFeRD
The normal case in Germany — and fully compliant: the invoice mailbox receives the attachment, VIM reads the XML part directly. For a pure XRechnung that means no OCR, no manual validation, no additional platform. With ZUGFeRD the embedded XML is first separated out of the PDF/A-3 and then takes the lead — whatever recognition reads off the image steps back behind it.
02
Peppol via an access point
Required where the network is mandated — Belgian B2B, public authorities in many EU countries. Two hurdles: nobody connects directly, it takes a certified access point. And Peppol wraps the UBL in a UN/CEFACT envelope (SBDH) that VIM cannot unpack — VIM processes plain UBL. SAP DRC performs that extraction; without DRC it becomes custom development.
03
SAP DRC or middleware
The tool class for multi-country compliance: DRC receives, validates and reports — as an eDocument, maintained per country by SAP. Worthwhile with clearance countries and reporting duties; usually overkill for a purely German intake. Alternatives are Peppol providers or existing middleware.
04
Paper and plain PDFs
The shrinking but stubborn legacy channel: paper gets scanned, PDFs arrive by e-mail — and whatever comes in unstructured is read by capture, classically with IC4S/CC4S or with AI extraction. Same DP document, same workflow: the process stays one.

What OpenText VIM already does out of the box

A lot of what gets budgeted as custom development in projects has been sitting in the standard delivery all along — the most common avoidable effort in e-invoicing projects. The state below matches VIM 25.4; comparing it against your own patch level is still worth it, as the list grows with every release.

01
Countries in the standard delivery
OpenText ships ready-made XML mappings: Italy (FatturaPA), France (Chorus Pro), Germany (XRechnung), Poland, Romania, Spain, Switzerland, Mexico, Vietnam, India and China — plus a generic UBL mapping for the Netherlands, Belgium and Japan. For those countries a project does not start from zero.
02
Three routes into the process
File upload via early archiving, e-mail via the inbound configuration, handover from the SAP eDocument environment. All three are standard, all three end in the same document — only the third one requires SAP DRC.
03
One intake for every format
A universal inbound handler processes paper, images, pure XML and hybrid formats in the same line, each with the steps that document actually needs. With ZUGFeRD and Factur-X the XML data leads and the data read off the image steps back. That saves you two separate worlds — and two operating models.
04
The return channel
Where a country demands a response, VIM gives one: acceptance on posting or parking, rejection on turn-down, duplicate, obsolete or return to vendor — with country-specific rejection reasons down to the Peppol codes, optionally with a comment for the supplier. The second reason DRC is rarely optional in clearance countries.
05
A readable view of the XML
Nobody reads an XRechnung — yet somebody has to approve it. VIM therefore renders a PDF view out of the mapped fields, grouped like an invoice and labelled in several languages, without a line of code. The common invoice fields come pre-configured.
06
Where the standard delivery ends
The connection to the government platform is not included: connectivity and middleware remain your job. Plus a few limits worth knowing before rollout — one invoice per XML file, signed Italian documents have to be unpacked first, and ZUGFeRD support ends at version 2.2 depending on your level.

Five misunderstandings that make projects expensive

01
“DRC replaces VIM”
No. The transmission route — e-mail, a Peppol provider or DRC — gets the invoice into the building; VIM turns it into a checked, posted document. One is the letterbox, the other is the mailroom with review and approval.
02
“We won’t need capture much longer”
Not for a long time. Foreign suppliers, transition periods, special cases: paper and PDF stay in the mix for years — only their share shrinks. Switch off capture before your last supplier has migrated, and you are back to manual work.
03
“ZUGFeRD is just a PDF”
ZUGFeRD is hybrid: there is an XML inside the PDF — and legally, the XML is what counts. If you only process the visible PDF, you may be processing the wrong data.
04
“Without SAP DRC there is no e-invoicing”
There is. Germany follows the post-audit model: no platform is prescribed, e-mail is enough. DRC is one tool among several — unnecessary for a purely German intake, but hard to avoid with Peppol and clearance countries, because there the envelope has to be opened and the return channel has to be served.
05
“This is purely an IT project”
Formats and channels are IT. But supplier communication, master data, review processes and exceptions are organization — and that is where e-invoicing either saves effort or merely shifts it.

The 8-point checklist for your invoice intake

Eight questions you should be able to answer today. Every “not sure” is a good reason for a conversation.

Receiving: can all your company codes accept e-invoices — including the central invoice mailbox?
Formats: are XRechnung and ZUGFeRD processed structurally — or is the PDF printed and scanned?
The ZUGFeRD trap: does your process read the embedded XML part or just the PDF view?
Supplier countries: which clearance countries — Italy, Poland, Romania, Greece — are on your vendor list?
Transmission route: is e-mail enough for you, or do you need Peppol, clearance or reporting — and with which tool?
VIM channels: are XML intake and capture configured cleanly and merged into the same process?
Master data: are VAT IDs, bank details and PO references correct? The most common reasons even structured invoices get stuck.
Issuing: who in your company issues e-invoices from 2027/2028 — and with what?

Who is behind this

SAP VIM expertisefrom ten years of project work.

This page is not written by an editorial team but by Johannes Auer: in SAP VIM projects since 2016, almost six of those years in the professional services team at OpenText, the maker of VIM, today with his own company. E-invoice formats, transmission routes and processing in VIM are his everyday project work, not knowledge from reading.

And whoever gets in touch talks to him directly — from the first call into everyday operation.

20+ projects10+ years in SAP VIMnearly 6 years at OpenText

Johannes Auer · Managing Director

Next step

Where does your invoice intake stand?

In 30 minutes we sort out your starting position: what you receive today, what the legislator demands tomorrow — and which transmission route actually covers it. No obligation, directly with the managing director.

Request a first conversation Book 30-min call

SAP VIM and the e-invoice: knowledge, condensed

Processing XRechnung and ZUGFeRD in SAP VIM

For VIM, an XRechnung is not an edge case but the most pleasant document there is: the data arrives structured, the DP document is created without OCR and without manual validation, and the business rules check PO reference, VAT ID and duplicates as usual. With ZUGFeRD, intake first separates the XML part out of the PDF/A-3; from then on the XML data leads, the data recognized from the image steps back and image validation is skipped. So that the approver still has something readable in front of them, VIM renders a PDF view out of the mapped fields — laid out like an invoice, labelled in the reviewer’s language. How robust your intake is today is exactly what the SAP VIM Executive Diagnostic shows.

When SAP DRC pays off — and when e-mail is enough

For a purely German invoice intake, DRC is not required: post-audit means no procedure is prescribed, and VIM processes an XRechnung arriving by e-mail directly. DRC plays to its strengths in multi-country operations — Peppol, clearance systems, statutory reporting — where it receives, validates and reports as an eDocument and hands the document to VIM. The return path is part of the deal: acceptance as soon as the invoice is posted or parked, rejection with a country-specific reason code when a document is turned down or confirmed as a duplicate — with exceptions running through the familiar VIM workflow. Whether DRC, a Peppol provider or none of the above: that decision belongs at the very start, and we make it together with you in SAP VIM Consulting.

From transition mode to permanent solution

Until 2028, paper, PDF, EDI and XML run in parallel — and precisely this mixed phase decides whether e-invoicing saves effort or merely shifts it. Consolidate intake channels now, clean up master data, and point the capture route — for instance with AI extraction via AIxVIM — at the shrinking paper share, and 2028 brings no migration stress, just one legacy channel switched off. If your move to S/4HANA falls into the same years, two initiatives share one test cycle and the same people — what hangs on that is laid out on the page about the SAP S/4HANA transformation.

Terms explained, one by one

The vocabulary of this topic, alphabetically — for looking up when the next meeting drops three acronyms per sentence again.

Access point (Peppol): A certified node in the Peppol network — and the only way to take part in it: nobody connects directly. Every participant sends and receives through their access point — like an e-mail provider, but with delivery confirmation and a central participant directory. For SAP VIM a second step follows: the UN/CEFACT envelope has to be opened, usually by SAP DRC.
Capture (IC4S / CC4S): The recognition components alongside VIM: OpenText Intelligent Capture and Core Capture for SAP Solutions read unstructured documents — paper and plain PDFs — and hand the data to the VIM process.
Clearance model: The state sits in the middle: every invoice passes a government platform before or during delivery, which validates and clears it — as in Italy (SdI) or Poland (KSeF).
CTC (continuous transaction controls): Umbrella term for models in which the tax authority sees transactions continuously rather than retrospectively — from real-time reporting through to full clearance.
DP document: The “document processing” object in VIM: the working document on which every incoming invoice is checked, enriched and brought to posting — regardless of the channel it came from.
DRR (digital reporting requirements): The reporting duties from ViDA: from July 2030, cross-border B2B transactions in the EU are reported digitally and promptly — based on structured e-invoices.
Early archiving (OAWD): The file-upload route: a document is archived first and thereby starts the VIM process. For e-invoices the simplest way in — you drop the XML file, the inbound handler does the rest.
eDocument (SAP): SAP’s framework for statutory electronic documents: the eDocument framework creates, sends and receives country-specific formats and is the technical basis of DRC. The eDocument cockpit shows every document with its status — from there the path leads into the VIM process, and from VIM Analytics back again.
EN 16931: The European norm for e-invoicing: a semantic data model defining which details an invoice contains and what they mean — the yardstick every format is measured against.
FatturaPA / SdI: The Italian invoice format and the state exchange platform Sistema di Interscambio — mandatory for domestic B2B invoices since 2019 and therefore Europe’s oldest clearance system.
GoBD: The German principles for proper keeping and retention of books in electronic form: they require, among other things, that the e-invoice is archived audit-proof as a structured data set.
Inbound configuration: VIM’s intake configuration: defines, per channel, which steps an arriving document runs through — read out, map, check, start the process. The place where it is decided whether XML and paper run in one line or in two.
KoSIT: The German coordination office for IT standards in Bremen: maintains the XRechnung standard and the German business rules for EN 16931.
KSeF: Krajowy System e-Faktur, Poland’s central invoicing platform: since February 2026, Polish B2B invoices must pass through this clearance system.
Leitweg-ID: The routing number in German B2G: identifies the receiving public authority and directs an XRechnung to the right place.
myDATA: The reporting platform of the Greek tax authority AADE: invoice data is reported there; since 2026 the mandatory B2B exchange via Peppol is tied to it.
OpenText VIM: Vendor Invoice Management for SAP Solutions: the workflow solution for invoice intake in SAP — business rules, role determination, exceptions, approval, posting. The core topic of this website.
Peppol: Originally “Pan-European Public Procurement OnLine”: an international network with common rules for exchanging electronic business documents. Participants connect through access points and are uniquely addressable.
Post-audit model: The counterpart to clearance: invoices are exchanged directly between business partners and the state checks only afterwards — Germany’s model so far.
RO e-Factura: Romania’s central invoicing platform: mandatory for domestic B2B transactions since January 2024, with full clearance since July 2024.
SAP DRC: SAP Document and Reporting Compliance: the SAP product for e-invoices and statutory reporting. It receives, validates, sends and reports — maintained per country by SAP, technically built on the eDocument framework. One of several tools for the transmission route: strong in multi-country operations, not required for a purely German intake.
UBL & UN/CEFACT CII: The two XML syntaxes in which an EN 16931 invoice is technically expressed: XRechnung permits both, ZUGFeRD uses CII, and UBL dominates in the Peppol network.
ViDA: “VAT in the Digital Age”: the EU package adopted in March 2025 that harmonises e-invoicing and digital reporting across Europe — with the major milestones July 2030 and 2035.
XRechnung: The German XML standard for e-invoicing, maintained by KoSIT — purely structured data without a visual file, mandatory in B2G since 2020.
ZUGFeRD: German-French hybrid format (“Zentraler User Guide des Forums elektronische Rechnung Deutschland”): a PDF/A-3 with embedded XML, a fully valid e-invoice from the EN 16931 profile upwards.

Frequently asked questions

Does SAP DRC replace OpenText VIM?
No — the two sit on different layers. DRC is one possible compliance and transmission layer: receive, validate, report. VIM is the processing layer: check, approve, post, handle exceptions. The transmission route can just as well be a plain e-mail — the processing layer is needed either way, otherwise the work moves back into accounting.
Do we need SAP DRC — or does it work without?
For a purely German invoice intake it works without. Germany follows the post-audit model: no platform is prescribed, exchange by e-mail is compliant, and VIM processes the incoming XRechnung or ZUGFeRD file directly. DRC — or a Peppol provider, or existing middleware — becomes relevant when Peppol is mandated, foreign clearance systems are involved, or statutory reporting has to be handled. What makes sense for you depends on countries, volumes and your SAP roadmap, not on a product decision made upfront.
Do we still need OCR and capture?
As long as suppliers send paper or plain PDFs: yes. The XML share is growing, but the transition takes years. The good news: in VIM both channels merge into the same process — you are not running two separate worlds.
Do we need separate processes for XML and paper?
No, and that is the real advantage. VIM ships an inbound handler that processes paper, images, pure XML and hybrid formats such as ZUGFeRD in the same line — each with the steps that document actually needs. After that, every invoice is the same document under the same business rules, whatever channel it came from. What it takes is clean channel control, not a second solution.
How does a human review an XML invoice?
In raw form, they do not — XML is made for machines. VIM therefore generates a readable PDF view out of the mapped fields, laid out like an invoice and labelled in the reviewer’s language. The approver sees a document, the machine processes the data — and what gets archived is still the XML, not the view.
What about invoices from abroad — KSeF, FatturaPA and the like?
Every country has its own model, from central clearing platforms to reporting obligations. There are several ways to connect: SAP DRC covers many of these countries and is updated continuously by SAP, and specialised providers and middleware solutions do the same. Which countries are relevant for you at all is a question of your vendor list — exactly what the first conversation is for.
How much time do we have?
In Germany you must be able to receive e-invoices already today. The obligation to issue them arrives in stages from 2027 — and a clean intake setup in VIM, with a transmission route such as DRC where needed, requires lead time for concept, customizing and testing. Planning in 2026 means being on time; starting in 2027 means being under pressure.
How does Johannes Auer IT Consulting support this?
We analyse your current VIM setup, design the target picture for e-invoice intake — with or without DRC — and implement it in VIM: customizing, intake channels, business rules, testing. Team training included on request.
Is a PDF invoice still an e-invoice?
No. Since 2025, Germany only recognises as an e-invoice what is issued, transmitted and received in a structured electronic format per EN 16931. A plain PDF is an “other invoice” — still permitted during the transition, but on its way out.
What is the difference between XRechnung and ZUGFeRD?
XRechnung is pure XML without a visual file — built for fully automated processing. ZUGFeRD is a hybrid: a PDF/A-3 with embedded XML that people can read and machines can process. Both are EN 16931 compliant from the appropriate profile upwards; in both cases, processing runs on the XML.
Does the German issuing mandate apply to small businesses?
Small businesses under § 19 UStG are exempt from the obligation to issue e-invoices. They must still be able to receive them, though — the receiving mandate knows no such exception.
Do we need a Peppol access point?
Only if you want or need to send or receive via the Peppol network — for example in Belgian B2B or towards public authorities in many EU countries. Important for SAP shops: the access point alone is not enough. Peppol delivers the UBL inside a UN/CEFACT envelope, and VIM only processes plain UBL. SAP DRC does the unpacking — without DRC it has to be built as a custom extension. For German B2B exchange by e-mail, Peppol is not a prerequisite at all.
How does an e-invoice have to be archived?
Audit-proof and GoBD-compliant — and it is the structured data set itself that matters. The XML must be archived, not just a printout or the PDF view. An archive that only stores the invoice image does not meet the requirement.

Official sources for further reading

When you need to be certain: the central points of reference, all official. The national authorities for individual deadlines are linked directly in the overview above.

Legal notice

This page is not legal advice.

What you read here is professional orientation from day-to-day SAP VIM consulting — not legal advice, tax advice or a legal service in the sense of the German RDG. We are neither lawyers nor tax advisors, and we may not and do not wish to advise on such questions.

All statements on deadlines, obligations, formats and countries were researched to the best of our knowledge (as of August 2026). This area of law changes constantly: dates are postponed, thresholds adjusted, regulations refined. Despite all care, individual statements may therefore be incorrect, incomplete or outdated. We accept no warranty for accuracy, completeness or timeliness, and liability for decisions made on the basis of this page is excluded.

What is binding is solely the applicable legislation in the country concerned. For your specific situation — in particular the tax and legal obligations of your company — please consult your tax advisor or lawyer. Our role is the technical implementation in the SAP system, not the legal assessment.