German e-invoices in SAP: what Core Capture 26.3 checks before VIM
Germany's dates are settled. Since 1 January 2025 every German company has had to be able to receive e-invoices in the EN 16931 format. Sending becomes mandatory on 1 January 2027 for companies above 800,000 euros in annual turnover, and on 1 January 2028 for everyone else. OpenText's Germany update also records the Finance Ministry's position that ZUGFeRD from version 2.0.1 counts as a structured e-invoice, and that in a hybrid invoice "the structured part will be the leading one."
For an AP team, that last line matters more than the dates. A ZUGFeRD invoice is a readable PDF with XML inside it, and the XML is the invoice for tax purposes. When the two disagree, the data wins. So the check that counts on an incoming German invoice is whether the data is valid. Whether the picture looks right is secondary.
What 26.3 adds. In late September OpenText announced Core Capture for SAP Solutions 26.3 on My Support (KB0871261). For German invoices the headline is validation of X-Rechnung and ZUGFeRD files against the KOSIT schema. The same release adds extracted fields that carry VIM business-rule error and warning counts, extraction of invoices with more than one VAT rate, and improvements to GenAI table voting. OpenText describes 26.3 as downward compatible with VIM and the Windows Validation Client, and offers a special VIM transport for VIM 25.4, 23.4, 20.4 and 7.6.
One naming point, because it trips people up in planning meetings. Core Capture for SAP Solutions is its own product. Capture for SAP Solutions and Capture Center are different products with their own lifecycle rows and their own alerts. KB0871261 applies to Core Capture only.
Validation gives you a result, not a decision. Somebody still has to say what happens to a German invoice that fails the KOSIT check. Back to the supplier? Into an AP exception queue? Through, with a warning on the record? Those answers live in your VIM process, and the new error and warning count fields give that process something concrete to route and report on once the rules exist.
We'd split it this way. The tax or AP compliance lead owns the list of formats and countries that must be validated. The VIM process owner owns what a failed or warned invoice does next. That's our view; OpenText's article describes the capability and doesn't assign roles.
Treat the transport as a change. The VIM transport is the piece most likely to sit in a queue, because it touches SAP and therefore goes through your normal transport path. Test it with real German supplier files, not samples: a clean XRechnung, a ZUGFeRD invoice whose PDF and XML disagree, and an invoice carrying two VAT rates. If you run VIM 7.6 or 20.4, OpenText's lifecycle page shows both leaving Current Maintenance on 31 December 2027. That doesn't stop you taking the transport. It's a good reason to build the test set so you can run it again on whichever VIM release comes next.
26.4 is a separate conversation. KB0873236 says Core Capture 26.4 rolls out from late September to early October, depending on data center. It brings Capture Aviator integration, an LLM extraction option, export improvements and column-level control over IEE learning on tables. Worth evaluating on your own invoices. Do that after the 26.3 validation rules are agreed, as its own change, so you can tell which release changed what.
Four things to answer this month:
Which of your German suppliers must start sending e-invoices on 1 January 2027.
Whether your Core Capture tenant is on 26.3, and who confirmed it.
Whether the VIM transport is in your test system yet.
What a failed KOSIT validation does to an invoice in VIM, in writing.
We'd rather help you build that test set in October than read the failures in January.
