Vendor invoice management: what SAP VIM does, and where an IDP tool fits

Vendor invoice management (VIM) is how a company handles the invoices its suppliers send, from receipt to payment. At companies that run SAP, VIM also names a product. OpenText makes it, and SAP offers it as SAP Invoice Management by OpenText. VIM runs inside SAP, where it checks each invoice and routes it for approval. E-invoices arrive as data and go straight into VIM. PDFs and paper scans need software to read them into data first. An intelligent document processing (IDP) tool can do that step.

Is VIM an SAP product?#

Vendor invoice management means two things. For most AP teams, it's the whole process of handling supplier invoices. At companies that run SAP, VIM usually means one product.

OpenText calls it Vendor Invoice Management for SAP Solutions. SAP lists the same product in its own catalog as SAP Invoice Management by OpenText. On its own site, OpenText calls VIM an SAP Solution Extension. Put simply, VIM is an OpenText product that SAP offers, not one that SAP built. OpenText also says it has 20 years of experience with VIM.

VIM works inside SAP itself. OpenText's FAQ says it runs as an add-on within your SAP ERP, so it needs no servers of its own. It supports every release from ECC 6 to the latest S/4HANA. That covers systems on premises and in S/4HANA Cloud Private Edition (RISE with SAP). Your team works in SAP screens and SAP Fiori apps. Besides invoices, VIM comes set up for other business documents, such as purchase orders, delivery notes and remittance advices.

How an invoice moves through VIM#

Inside SAP, VIM moves each invoice through the same main steps. If an invoice passes VIM's checks, it goes on to approval and posting. If it fails one, VIM sends it to the person whose job is to fix that kind of problem.

OpenText builds these checks from rules, roles and actions. A rule describes something a person would normally check, such as a duplicate invoice or a price that doesn't match the PO. A role links a business job to a person or a team. An action is a ready-made fix for a problem, such as posting a missing goods receipt. Invoice validation lists the checks AP teams run before an invoice posts.

Approvals can run in parallel, and they escalate when nobody acts. VIM records every action people take in an audit trail. Dashboards show where invoices are waiting and how big the backlog is.

Which invoices need reading before VIM#

VIM checks data, so each invoice has to become data first. How that happens depends on what the supplier sends.

OpenText's own product overview draws the same line. It says VIM takes in documents from business networks, EDI, email, upload or scan. For data capture from PDFs and images, it names two OpenText capture products that work with VIM. So even in OpenText's own lineup, reading a PDF is a separate product.

How many of your invoices need this step depends on your suppliers. Ardent Partners' State of ePayables 2025, a sponsored analyst report, found that 57% of suppliers can now send invoices electronically. Check what "electronically" means for your own suppliers. A PDF sent by email arrives electronically, but it still has to be read.

What keying PDF invoices by hand costs#

Some teams still key PDF and scanned invoices into SAP by hand, with or without VIM. The calculator compares that manual work with automated capture. Enter only the invoices your team keys by hand. Leave out the e-invoices that VIM maps on its own.

Ardent's report puts the average cost of processing one invoice at $9.84. It puts the average exception rate at 18.4%. It also says exceptions are usually the biggest single reason AP benchmarks, such as that $9.84 cost, aren't lower. The calculator starts with both figures. Change them to your own, including the share of invoices that would still need a person.

The result is the most you could save, not a forecast. The calculator counts every invoice that skips a person as costing only the software. It leaves out the work to connect a capture tool to SAP. With Docsumo, that means building the step that receives the data, because there's no packaged SAP connector.

If you already use a capture product, the calculator overstates the gain. Look at VIM's reports instead, which break invoices down by exception type. Count the exceptions where the reading step missed or misread a field. Only those can go away with a better reading step. A real price or quantity mismatch stays an exception, whatever reads the invoice. Touchless invoice processing explains how to measure the share of invoices that pass without a person.

Three ways to read PDF invoices in an SAP system#

If PDFs and scans are a real share of your invoices, something has to read them before VIM. There are three kinds of tool to choose from.

• OpenText capture products

  OpenText offers two capture products that work with VIM. Core Capture for SAP Solutions runs as software as a service (SaaS) in OpenText's cloud. It keeps its settings in SAP, and your team checks the results in SAP Fiori. Capture for SAP Solutions is an add-on to OpenText Capture, which OpenText says can run on premises.

• SAP Document AI

  SAP Document AI is a managed service on SAP Business Technology Platform (BTP). SAP says it turns invoices, purchase orders, delivery notes and other documents into structured data. It can send that data to S/4HANA Cloud, to ECC or S/4HANA on premises, or to other systems. SAP's page doesn't mention VIM.

• An IDP platform

  An IDP platform such as Docsumo reads the PDF or scan. Fields it isn't sure of go to a reviewer before the data reaches SAP. Docsumo has no packaged SAP connector. It connects to SAP through the API and webhooks, so your SAP team builds the step that receives the data.

Our take. Don't pick a reading tool by what its maker calls it. OpenText calls its products capture, and SAP's product is SAP Document AI. Other vendors say IDP, document AI or document intelligence, and all of these name one category. Each tool turns a PDF into fields. So send the same month of your own PDF and scanned invoices through each option, and count how many invoices still need a person.

When you don't need another tool#

A separate reading tool isn't always worth adding. Pick the line that sounds most like your invoices.

How Docsumo connects to SAP#

Docsumo works before SAP, not inside it. Here is the path an invoice takes.

1. Invoices arriveSuppliers' PDFs and scans reach Docsumo by email, upload or the API. Docsumo has its own inbox for emails. On the Business plan, it sorts invoices from other documents and splits files that hold more than one.
2. Docsumo reads themIt reads the fields on each invoice, including handwritten text such as a PO number written on a scan. When a table runs across pages, it joins it into one table. It flags an invoice that duplicates one already received. The invoice extraction page lists the fields.
3. A person checks the unsure fieldsEach field gets a confidence score. A field below the level you set goes to a reviewer, who clicks it to see the line it came from.
4. The data goes to SAP through the API and webhooksDocsumo has no packaged SAP connector. Your SAP team or integrator maps its fields to SAP and builds the step that receives them. The integrations page shows the API and webhooks.
5. SAP takes overPosting and payment stay in SAP. If you run VIM, approvals stay in VIM. Docsumo doesn't pay vendors.

VIM itself runs inside SAP, and OpenText says no data leaves your system. The reading step can work differently. Core Capture runs in OpenText's cloud, and SAP Document AI runs on SAP BTP. Docsumo is cloud only, so your invoices are read in Docsumo's hosted service, with nothing to install on your own servers. You can choose where your data is hosted, including the US, the EU (Frankfurt) and the UK (London). Docsumo is SOC 2 Type 2 audited and ISO/IEC 27001:2022 certified, and the security page lists its controls.

Valtatech, an accounts payable automation provider in Melbourne, uses Docsumo on the supplier invoices it handles for clients. It processes 99%+ of them touchless, at 65%+ lower data processing costs. The Valtatech story has the details.

If most of your VIM exceptions come from PDF invoices#

Pull last month's exceptions from VIM's reports and sort them by type. Count the ones where the reading step missed or misread a field on a PDF or a scan. If there are only a few, keep your reading step and look at price and quantity exceptions instead. If there are many, send those same invoices through two or three reading tools, and count how many still need a person.

Book a demo with a month of your PDF and scanned invoices, or start a free trial.

Frequently asked questions#