Treat e-invoicing as an inbound channel, not a capture afterthought
Inbound is no longer “the scan folder”
A lot of VIM landscapes were designed around a packet: email or scan, image in the archive, extraction, validation, process. That packet still exists. It is no longer the only packet.
OpenText’s current VIM product page describes structured inbound in plain language: mapping logic that converts structured data into header and line-item fields, common mappings out of the box, an interactive mapping editor, a PDF rendition so people can still read the document, and integration with SAP Document and Reporting Compliance and OpenText Trading Grid e-Invoicing. After receipt, processing can start automatically. Where a government connection requires it, accept or reject feedback can go back to the connected service.
That is a different inbound job than “run OCR on a PDF.” If you treat a mandated e-invoice as another image for capture to interpret, you throw away the structure you were given, and you still have the compliance clock.
Channels you should name on one page
Use names your landscape actually has. A useful public checklist from the 2026 landscape note includes email, scan, IDoc, Ariba, Transportation Management, DRC, and custom APIs. Add Trading Grid where you use it.
A practical channel map:
Unstructured image — PDF or paper. Capture and validation earn their keep.
Structured file / IDoc / EDI — mapping, not OCR. Exceptions are about content and master data, not characters.
Business network (for example Ariba) — posting problems need the right user at the right time; OpenText’s overview calls this out explicitly.
DRC / government-clearance flows — receipt and response are part of the process, not after posting.
Trading Grid e-Invoicing — a network path into the same VIM process, not a second AP system.
Freight / TM-related invoices — optional add-ons exist; do not hide them inside “other.”
You do not need every channel. You need to stop pretending they are one.
Mapping is a configuration practice
Structured invoices fail in mapping the way images fail in extraction. Someone owns the map. Someone updates it when a supplier changes a format. Someone decides what the PDF rendition is for (human reading, audit, both).
A measured inbound practice:
One inventory of channels and volumes. Approximate is fine. Silence is not.
For each structured channel: source, mapping object, failure queue, and the person who may change the map.
For each image channel: capture product, validation workplace, and the person who may change profiles.
A single archive and ArchiveLink story so every channel still produces a retrievable image or rendition.
Country scope. E-invoicing mandates are not a generic “global AP” feature. They are country programs that happen to share a platform.
Do not set one automation KPI across all channels. A structured clearance invoice and a photographed utility bill should not share a success rate.
What this means for capture and validation
Capture does not disappear. Mixed landscapes remain normal; OpenText says so. The point is honesty about work:
Validators should not re-type fields that already arrived as structured data.
Processors should not treat a DRC reject as a “VIM exception” with no compliance owner.
IT should not upgrade Foundation without listing DRC and network integrations on the test plan. They are on the public checklist because they break in silence.
Fiori workplaces and AP workspaces matter more as channels multiply. People need to see the rendition, the mapped fields, and the process status without opening three clients.
Clean core and extensions
OpenText describes VIM as running in the SAP instance, with room for small on-stack or BTP extensions—including additional enrichments or AI scenarios through ISLM. E-invoicing is a poor place for a shadow integration. If a government platform needs a response, that response should be a named step in the process you already run, not a side job on someone’s laptop.
SAP’s published VIM accelerator (dashboards for exception rates, user activity, flows, cycle time) is one way some teams watch the mix. You can also watch it with the reports you already have, if you tag the channel. Tag the channel.
Competitor noise, used carefully
This week’s public partner feed was not about e-invoicing first. One partner note in an early August post was pushing modern-versus-legacy VIM and reporting. Another partner public site still frames fast-track VIM and, separately, AI-agent stories we will not repeat as facts. And yet another partner deveoped content material leans implementation and extensions. And finally a spring note was about sustaining capture. None of that replaces a channel map.
We will not cite their metrics. We will say what OpenText and SAP Community already say: structured e-invoice integration is part of the current product, and inbound variety belongs on the upgrade and operating checklist.
Start with a map, not a mandate project
If a country mandate is already live, you have a process. Write it down in VIM terms. If a mandate is coming, add the channel before you add staff. If you have no mandate, you may still have EDI or Ariba. Those are structured inbound too.
McCloy Data can help you draw the map and test the pairings (Foundation, capture, archive, DRC, network) without turning it into a transformation program. Then your image-based capture work has a clear job, and your structured work has a clear job. That is enough for one Friday.