Upcoming product. Not released. There is no release date and we are not going to invent one.
Invoices arrive by email or from another system, as PDF or as an image. InvoicePipeline is intended to parse them, run them through a control and approval workflow, and post them into SAP through released SAP interfaces. This page describes the problem it addresses and the design we are building. It does not describe a finished product, and where something is an intention rather than a decision, it says so.
We are not taking payment, we are not taking orders, and if your situation is one the first version will not handle, we will tell you that instead of adding you to a list.
Because the people who have this problem are the people whose requirements should shape the first version, and because they are much easier to find while the design is still movable than after it is fixed.
The alternative — waiting until the product is finished and then discovering which assumptions were wrong — is how most accounts payable software ends up almost fitting. Non-PO coding rules that no organisation actually uses. An approval matrix that assumes a hierarchy nobody has. A tolerance model that ignores the fact that quantity variances and price variances are argued with completely different people.
So the page is here early, and it is written to be recognised rather than admired. If the description below sounds like a brochure written by someone who has never watched an accounts payable team work, close the tab. If it sounds like your Tuesday, we would like to hear from you.
Minimal Code Systems AG is a Swiss-headquartered engineering company. InvoicePipeline sits alongside SAP Signavio Consulting, which is not a coincidence: the problem below is one you find by measuring processes, and it is the one we keep finding. More about who we are.
If you run AP on SAP, skip to the next section — you know this. It is written out in full because the rest of the page only makes sense against it, and because an unfinished product has to prove it understands the problem before it says anything about a solution.
Invoices arrive at a shared mailbox. Some are PDFs generated by a supplier's billing system. Some are scans. Some are photographs taken at an angle by a site manager holding a delivery note in the other hand. Some arrive as attachments to a reply in a thread about something else. Some are forwarded twice by two different people, three days apart.
A few arrive as structured electronic documents, from suppliers who are ahead of everyone else or who are already subject to a mandate. Those are the easy ones, and they are still a minority in most mailboxes.
Somebody opens each of them. From the moment an invoice lands until somebody opens it, there is no record that it exists — which is why nobody can answer "what is sitting unprocessed right now" without a person counting, and why the month-end accrual for goods and services received but not invoiced is an estimate made under time pressure.
PO invoices go to logistics invoice verification. Header data, then the lines matched against the purchase order. If the goods receipt exists and the quantities and prices are within tolerance, this is a good day.
Non-PO invoices — services, utilities, rent, professional fees, insurance, subscriptions, the long tail that is small in value and enormous in volume — go the FI route as a vendor invoice, and now somebody has to decide what the invoice actually is. General ledger account. Cost centre, or WBS element, or internal order. Profit centre. Tax code. Sometimes a split across several of those.
That decision is frequently a guess made by a person who was not involved in the purchase and cannot tell from the document what it was for. It is corrected later, sometimes, by someone in a reporting function who also does not know, or by a cost centre manager who spots it in a monthly report six weeks after the fact and raises a reclassification. Every one of those corrections is a journal entry, an explanation and a small permanent loss of confidence in the management reporting.
The organisations with the worst version of this problem are usually the ones with the strongest procurement policy on paper, because the policy says all spend requires a purchase order and the reality is that a large share of the invoices in the mailbox do not have one. Which nobody wants to write down.
Quantity and price on the invoice, checked against the purchase order and the goods receipt. Anything outside the tolerance limits configured for the company code sets a payment block, and the invoice is now a case rather than a transaction.
The block reasons are not equivalent and they are not resolved by the same people:
A price variance is an argument with procurement or with the supplier, about a purchase order that may be a year old and a price that may have been renegotiated verbally.
A quantity variance is an argument with the receiving site, and it is usually a goods receipt that was not posted, was posted late, was posted against the wrong line, or was posted for the whole delivery when half of it was rejected.
A date variance is often nothing at all, and it still consumes the same amount of somebody's attention.
A small difference below the automatic-adjustment threshold is absorbed silently, and the threshold is one of those settings that was configured once by a consultant who left.
The blocked invoice then enters the part of the process that consumes the actual working day. An email to procurement. An email to the receiving site. A call to the supplier. A spreadsheet of blocked items reviewed weekly in a meeting. A GR/IR balance nobody wants to own and a periodic clean-up that clears differences whose origin nobody remembers. And eventually a release, in MRBR, once three people agree about what happened several weeks ago.
Meanwhile the supplier is phoning, and the person answering the phone cannot see why the invoice is blocked without opening two transactions and knowing which one to open.
The person who has to approve the non-PO invoice is a budget holder. They do not have an SAP licence, they do not want one, and they are not going to get one — and even if they did, they are not going to be taught a transaction code for something they do six times a month.
So the PDF is forwarded by email. The approval decision lives in an inbox. Approval authority is determined by a matrix that exists as a spreadsheet, maintained by one person, out of date since the last reorganisation, and not readable by any system. Delegation during holidays is handled by a colleague replying "approved on behalf of" with no record of the delegation.
Then the auditor asks who approved this invoice, on what basis, and whether they were authorised to approve that amount for that cost centre. The audit trail is a mail thread — assuming the person is still with the company, and assuming their mailbox was not deleted when they left.
Structured electronic invoicing obligations are arriving across Europe on a country-by-country timetable, with different formats, different transmission networks and different phase-in rules by company size. Several major economies have already fixed dates, and the direction of travel at EU level is towards digital reporting of cross-border transactions rather than away from it.
The practical consequence for an AP team is not that PDFs disappear. It is that the mailbox becomes more heterogeneous, not less: structured documents from suppliers subject to a mandate, PDFs from those who are not, images from the long tail who will never be, and a compliance layer that has to receive, validate and archive the structured ones in a legally defined way.
We are not claiming that InvoicePipeline solves that. Compliance receipt and reporting is a specific, regulated capability, and SAP has its own answer for it. What we are saying is that any intake design built today has to assume a mixed inbound stream for years, and has to be able to sit alongside a compliance layer rather than compete with it. Which is a design constraint, and we would rather state it than discover it.
None of this is a failure of the finance team. It is a process that requires a human being to act as an integration layer between a mailbox, a purchasing system and a general ledger. That is the problem.
Everything in this section is design intention for an unreleased product. Where a decision is still open, it is marked as open. We would rather this page be dull and accurate than exciting and wrong.
Invoices arrive at a monitored mailbox, or are handed over by another system that already holds them: a document management system, a supplier portal, a scanning service, a shared folder.
The document is registered on arrival. That single act is a larger change than it sounds, because from that moment there is a record that this invoice exists, with a timestamp, a source, a sender and a status — which is what makes "what is unprocessed right now" a query rather than a counting exercise, and what gives the period-end accrual something to be based on.
Formats: PDF, including PDFs that are really just a scan wrapped in a PDF, and common image formats. Where a structured electronic document arrives, the structured data is used directly rather than read off a rendering of it — that is the whole point of it being structured.
The document is read and the fields are extracted. Supplier identity and bank details as printed. Invoice number, invoice date, currency, net, tax and gross amounts, tax rate and where present the tax registration numbers. Payment terms as stated on the document. Purchase order reference, delivery note reference, contract reference. And the line items, which are the part that separates a serious tool from a header-only one.
For scanned and photographed documents this involves optical character recognition, which is a mature and unremarkable technology. We are not going to call any of this AI, and you should be cautious with anyone who does — particularly if the claim comes with an accuracy percentage that was measured on their sample rather than yours.
What we will say is that extraction is never perfect on the first document from a new supplier layout, and that the honest measure of an intake product is not its accuracy on a clean PDF. It is how quickly and cheaply a human can correct an extraction, and whether that correction improves the handling of the next document from the same supplier. That is the part we are designing for.
Extracted values are checked rather than trusted. The intended checks:
This stage is where an intake product either earns its place or becomes an expensive scanner. Extraction produces a guess. Validation against your actual master and transactional data turns the guess into something you can act on, and turns the exceptions into a short, specific list rather than a general sense of unease.
Rules decide what happens next, and the rules are yours.
The clean PO invoice — supplier known, purchase order open, goods receipt posted, quantities and prices inside tolerance, no duplicate signal — is intended to go through without human involvement.
The exception goes to a queue built for resolution rather than for re-keying. The invoice, the purchase order and the goods receipt shown together, with the variance identified and quantified, so that the person resolving it can see all three without opening three transactions and remembering which is which. Routing by exception type, because a quantity variance and a price variance are resolved by different people and there is no reason to send them to the same queue.
The non-PO invoice is coded and routed. Coding proposals are intended to be derived from your own history for that supplier and that cost object, and from rules you configure — not from a black box, and always visible and changeable by the person responsible. Routing follows your approval authority rules, which is the point at which most implementations discover that their approval matrix is not written down anywhere a system could read.
Approvers work in a plain web interface. On a phone, if that is where they are. Without an SAP licence, without a transaction code, and without training beyond one screen. They see the document, the coding, the amount, the budget context they need, and two buttons and a comment box.
Everything is recorded as it happens. Who, when, on what grounds, against which version of the document, under which delegation if any. Recording it as it happens costs nothing. Reconstructing it afterwards is what makes audits expensive and, occasionally, inconclusive.
The finished invoice is posted in SAP — or parked, where your controls require a second pair of eyes inside SAP itself — as a logistics invoice against the purchase order, or as an FI vendor invoice where there is no purchase order.
The source document and the full decision trail are intended to be attached to the resulting SAP document, so that the evidence lives where the accountant, the auditor and the person answering the supplier's phone call will actually look for it, rather than in a second system they have to be told about.
SAP remains the system of record. InvoicePipeline is intended to be the thing that gets an invoice ready to be an SAP document, not a parallel ledger.
The intended result is that the routine invoice goes through without anyone touching it, and that your team spends its time on the exceptions — which is the only part of the job that ever needed people.
This section exists because it is the first technical question any SAP programme lead asks, and because the answer is checkable.
The design intention is that InvoicePipeline creates supplier invoices in SAP exclusively through the interfaces SAP publishes and supports for that purpose — the released supplier invoice service on SAP S/4HANA, and the released function modules for logistics invoice verification and for financial accounting documents where the target system is SAP ECC.
It is intended that InvoicePipeline performs no direct writes to SAP database tables, and no modifications to SAP standard objects.
The reason is not architectural purity. It is that direct table writes bypass the validations, substitutions, authorisation checks, number ranges and update logic that make an SAP document correct, and they turn every upgrade and every support package into an incident with your name on it. If you are running a clean core programme, a supplier that writes to your tables is a finding.
| Scenario | Where the invoice lands |
|---|---|
| With a purchase order | Created as a logistics invoice referencing the purchase order and, where relevant, the goods receipt — so that your existing three-way match, your tolerance configuration and your payment block behaviour continue to apply. We do not intend to reimplement your matching rules outside SAP and then post a document that pretends the match happened. Your configuration stays the authority. |
| Without a purchase order | Created as a vendor invoice in financial accounting, with the coding produced by the workflow — general ledger account, cost object, tax code and any split — carried into the document. |
| Parked rather than posted | Where your control model requires it, so that an SAP-side reviewer completes the posting. |
This is an architectural intention, not a completed and verified implementation. It is the right intention and we are confident in it, but the product is unreleased and the specific interface used per scenario, per SAP release and per deployment model has to be confirmed against your system — including whether attaching the source document to the SAP document uses the mechanism your organisation already uses for archived documents, and including how your particular ECC release differs from the current cloud interface set.
Ask us about it directly. If the answer for your release is "we have not tested that yet", that is the answer you will get.
A page about an unreleased product is only worth reading if the exclusions are as clear as the inclusions.
Where invoices arrive as documents rather than as structured data and somebody keys them.
If most of your volume is clean PO invoices already settling automatically, your problem is smaller than this page assumes. If a large share is services, utilities, professional fees and subscriptions that have to be coded by hand, this is aimed at you.
Who own the invoice process end to end and are tired of being the integration layer between a mailbox and a ledger.
Which is nearly all of them — and where the approval evidence currently lives in email.
Who want to fix the intake process without making the move harder. This is a group we specifically want in the early-access programme, because the interface set differs and we would rather design for both than retrofit one.
Discount capture, cycle time, blocked invoice backlog, accrual accuracy, or an audit finding about approval evidence.
Early users shape what ships first. We would rather have a small number of specific conversations than a large mailing list, so the programme is deliberately a conversation and not a form submission that disappears.
Bring the answers if you have them, and if you do not, that is a finding rather than a problem.
We do not know, and we are not going to name a date to make a page look more finished than the product.
It is in development. It is not released. We are not taking payment for it, we are not taking orders, and nothing on this page is a commitment to ship a specific capability on a specific day. Anything here described as an intention may change, including in response to what early users tell us — which is rather the point of publishing it now.
What we can do today is show you where it has actually got to, take your requirements seriously while they can still change the design, and tell you honestly whether your situation is one the first version will handle. When there is something real for you to look at, we will contact you. If the fit is poor, we will tell you that instead of keeping you on a list until it is awkward.
The intention is both, and we are treating ECC as a first-class case rather than as a compatibility afterthought — a large number of the organisations with this problem are on ECC today and will be for some time, and several of them are planning an S/4HANA move that this problem is making harder rather than easier.
Practically, the interface set differs between the two, and so does the effort. This is exactly why we want ECC organisations in the early-access programme: designing for both from the start is achievable, and retrofitting one afterwards usually is not.
We are not going to publish a support matrix for an unreleased product. Tell us your release and deployment model and we will give you a specific answer, including "we have not tested that combination" where that is the truth.
The design intention is that invoices are created exclusively through the released SAP interfaces for supplier invoices — the released supplier invoice service on S/4HANA, and the released function modules for logistics invoice verification and financial accounting documents on ECC — with no direct writes to SAP database tables and no modifications to SAP standard objects.
That means your existing configuration stays the authority: your tolerance limits, your block logic, your number ranges, your validations and substitutions, your authorisation checks. We do not reimplement your matching rules outside SAP and post a document that asserts the match happened.
We are flagging this on the page as an architectural intention rather than a verified implementation, because the product is unreleased and the specific interface per scenario and per release has to be confirmed against a real system. It is the answer we want to give and the one we are building towards. Ask us directly and you will get the current, unvarnished state of it.
No, and we are not going to describe it that way to make it sound more impressive.
Reading a scanned or photographed document involves optical character recognition, which is decades old and unremarkable. Everything after that is field extraction, validation against your SAP master and transactional data, and a workflow you configure. Automated parsing and rules.
We are also not going to publish an extraction accuracy figure, because accuracy measured on somebody else's document sample tells you nothing about your suppliers' layouts. If accuracy matters to you — and it should — the meaningful test is your own invoices, and that is one of the things the early-access programme is for.
Alongside, not instead of. Receiving, validating, archiving and reporting legally mandated electronic invoices is a regulated capability with country-specific rules, and SAP has dedicated products for it. We are not proposing to replace that layer and we are not claiming support for any national mandate or structured format.
What we are designing for is the consequence: for years to come your inbound stream will be mixed. Structured documents from suppliers subject to a mandate, native PDFs from those who are not, and images from the long tail who never will be. An intake design that assumes everything becomes structured will be wrong, and an intake design that assumes nothing does will be wrong differently.
So the constraint we are building to is that InvoicePipeline should take the documents that are not handled by a compliance layer, and should not get in the way of the ones that are. We ask early users which formats and networks they already receive precisely so this stays a design constraint rather than a surprise.
Nothing, and it is deliberately structured that way. No cost, no purchase order, no notice period, no exclusivity, and no obligation to buy anything if and when there is something to buy. You can stop at any point. We will not name you publicly or write a case study — our whole site carries no client names by decision.
On data: nothing has to move anywhere for the first conversations, which are about your process rather than your documents. If and when you want to share a sample of invoices, that happens under whatever redaction, anonymisation and agreement your legal and data protection people require, and we will work to your process rather than ours. We would not ask for access to a production SAP system at any stage.
Where the software would eventually run is one of the decisions still open. We operate our own data-centre cage space and systems in Zurich, Frankfurt and Istanbul, and deployment inside your own environment is on the table. If you have a hard requirement — a jurisdiction, a hosting model, a separation rule — tell us early, because it is the kind of requirement that is cheap to design for now and expensive to add later.
The product is not finished. The problem is, and it is one we keep finding when we measure how organisations actually run.
If the description on this page matches your process — the mailbox, the blocked invoice backlog, the approver who will never have an SAP licence, the discount that was lost to inertia rather than to a decision — then a conversation now is worth more to both of us than a conversation after the first version is fixed.
Request early access and tell us the awkward part. We will tell you honestly what exists today and whether the first version is likely to help you.
And if what you actually need is to understand and quantify the problem before you consider any software at all, that is a different piece of work and we do it: see SAP Signavio Consulting.
We reply to enquiries within 2 business days.
Part of Business Process & Automation. See also SAP Signavio Consulting.
