Beyond the Transaction: Why SAP Runs the Record but Someone Still Has to Manage the Supplier, the Customer, and the Approver

An invoice arrives for 4,180 units of a bearing assembly. The purchase order says 4,000. The goods receipt says 4,000. SAP does exactly what it was designed to do, which is refuse to pay something that does not reconcile. The document lands in MRBR with a quantity variance block, and the transaction stops there.

What happens next has nothing to do with SAP.

Someone opens Outlook and searches for the supplier contact. Someone emails the buyer to ask whether an over-delivery was authorized. Someone waits two days, gets no reply, and forwards the thread again with "following up" in the subject line. Someone eventually finds out the supplier shipped an overage against a blanket agreement that was never converted into a scheduling agreement line. A credit memo gets requested. The plant confirms it consumed the extra units anyway. The buyer approves the variance verbally in a hallway conversation, then forgets to document it. Eleven days after the invoice hit the system, a clerk releases the block in MRBR and types a two-word note into the header text field that nobody will ever read again.

The SAP part of that story took four seconds. The human part took eleven days. And here is the uncomfortable detail that finance leaders keep running into: the four seconds are already automated, measured, audited, and optimized to death. The eleven days are invisible. They live in inboxes, spreadsheets, Teams threads, and the memory of the one person on the team who knows how this particular supplier behaves.

SAP Is a System of Record, Not a System of Work

This is not a criticism of SAP. It is a description of the design.

An ERP exists to hold the authoritative version of a business fact. What was ordered, what was received, what was invoiced, what was paid, what was recognized as revenue, what remains as a liability. The value of that record comes precisely from its rigidity. If the three-way match tolerance is fifty dollars, then a fifty-one dollar variance stops. If the release strategy says a spend of that size requires a second signature, then it waits for a second signature. Auditors love this. Regulators love this. CFOs sleep at night because of it.

The rigidity creates a side effect. Every time reality fails to conform to the record, the system produces a stop, and a stop is not a resolution. It is a request for a human being to go find out what actually happened in the world and then tell the system what to do about it.

Think about how much of the daily work in a finance or supply chain function is exactly that. A blocked invoice. A customer purchase order that arrived as a PDF with part numbers that do not map to your material master. A sales order that failed a credit check for a customer whose payment behavior has been fine for six years. A goods receipt posted against the wrong plant. A payment that came in short by an amount that matches a promotional allowance nobody logged. A vendor master change request sitting in a queue because the bank detail letter is unsigned.

None of these are SAP problems. SAP behaved correctly in every case. They are problems that exist in the space between the record and the people who create the underlying reality.

The Three Parties Standing Around Every Stopped Transaction

When a transaction stops, the work that follows almost always involves one of three counterparties, and each one behaves differently.

The supplier sits on the upstream side. They send documents in formats you did not choose, on a cadence you do not control, with references that may or may not match your PO numbering. When something breaks, resolution requires a conversation with someone outside your organization who has their own priorities and their own ERP. The supplier does not care that your invoice is sitting in MRBR. They care that they have not been paid, which is why the follow-up email you eventually receive is usually a dunning notice rather than a helpful explanation.

The customer sits downstream. They send purchase orders through portals, EDI feeds, email attachments, and occasionally a fax that gets scanned by a receptionist. Their PO does not use your material numbers. Their delivery terms contradict the ones in your contract. Their accounts payable department takes a deduction for a co-op advertising allowance and codes it against an invoice from four months ago. Every one of these creates a stop somewhere in SD or FI-AR, and every stop requires someone on your team to reconstruct what the customer meant.

The approver sits inside. They are usually the hardest of the three to manage, which surprises people. Internal approvers are cost center owners, plant managers, category buyers, and controllers who have a day job that is not approving your documents. They receive a workflow item in their SAP inbox, or a notification email they have trained themselves to ignore, and the document waits. Escalation is awkward because the approver outranks the person doing the chasing. So the chasing happens through gentle reminders, calendar nudges, and, eventually, a manager-to-manager conversation.

Three relationships, three sets of context, three completely different rhythms. SAP holds a single field that says the document is blocked. It holds nothing about which of these three loops is open, how long it has been open, who owes whom a response, what was already tried, or what happened the last four times this exact situation arose with this exact counterparty.

That missing context is the actual work.

Why Exception Volume Refuses to Go Down

Most organizations that have run SAP for more than a few years have already attacked this problem once. They implemented OCR for invoice capture. They set up a vendor portal. They pushed customers onto EDI. They tightened tolerances, cleaned the vendor master, and ran a project to reduce touch rates.

Touchless rates improve, and then they plateau. The reason is structural.

Straight-through processing handles the population of documents that conform. Conforming documents are the easy ones by definition, which means every improvement project harvests the most tractable portion of the remaining volume and leaves behind a residue that is harder than what came before. After three rounds of this, the exceptions that remain are the ones that resist rules entirely. They are the invoices from the supplier who bills freight separately on odd-numbered months. The customer whose PO revision numbers increment in a pattern that matches nothing. The intercompany scenario that only occurs at quarter close.

Meanwhile the population of documents keeps growing, so a stable exception percentage against a growing base produces a growing absolute number of stopped transactions. A team that handled 400 exceptions a month at a 12 percent rate handles 700 a month two years later at 9 percent, and the 9 percent looks like progress on a slide while the people doing the work feel further behind than ever.

There is a second reason the plateau is so stubborn. Rules-based automation is good at deciding, and bad at investigating. A rule can tell you that a variance is outside tolerance. It cannot read the last six emails with that supplier, notice that the account manager already agreed to absorb the difference, find the agreement referenced in an attachment, and connect that agreement to the PO line. That investigative step is where the eleven days go, and it is the step almost nobody has automated because it does not look like a transaction. It looks like reading.

Orchestration Is the Layer Nobody Bought

The gap has a name. It is orchestration, and it means managing the work around a transaction rather than the transaction itself.

An orchestration layer does not replace SAP and does not compete with it. It sits alongside the ERP and takes responsibility for everything the ERP was never designed to hold. It watches for stops. It classifies them by cause rather than by symptom. It gathers the evidence needed to resolve them from wherever that evidence lives, which is usually email, attachments, contracts, portals, and prior cases. It runs the conversation with the supplier, the customer, or the approver on a schedule that does not depend on someone remembering to follow up. And when the answer is known, it writes the resolution back into SAP through the proper transaction so the record stays authoritative and the audit trail stays clean.

The distinction that matters is between deciding and doing. SAP decides. Workflow tools route. An orchestration layer does the legwork in between, which is the part that has historically required a human to hold context in their head across days and channels.

At Artificio we build this layer with document AI agents rather than template-based extraction, and the reason is directly connected to the exception problem. Template systems break on the documents that matter most, because non-conforming documents are the definition of an exception. An agent that reads a supplier statement, understands that four line items reference invoices you have already paid and one references an invoice you never received, and then drafts the query back to the supplier, is doing investigative work rather than field extraction. That difference is what allows the residue to move.

The Supplier Loop in Practice

Take accounts payable, where the pattern is most visible.

An invoice arrives and fails the three-way match on price. The cause could be a dozen different things. A PO that was never updated after a negotiated price change. A supplier billing at list rather than contract. A currency conversion applied on a different date. A rebate that should have been netted. A freight charge that belongs on a separate line. Each cause has a different resolution path, and the resolution path determines who needs to be contacted and what needs to be asked.

Classification by cause changes the shape of the work. Instead of a queue of 300 blocked invoices sorted by age, you get a set of buckets. The 40 that are contract-price mismatches route to the category buyer with the contract clause and the PO line attached. The 55 that are unbilled freight route to a standing rule that either accepts within a threshold or queries the supplier with a pre-drafted message. The 12 that are genuine duplicates get flagged with the matching document reference so nobody spends twenty minutes proving it.

The supplier conversation itself becomes managed rather than ad hoc. When a query goes out, the system knows it went out, knows what was asked, knows when a response is due, and escalates on its own schedule. When the supplier replies with an attachment, the reply gets read, matched back to the open case, and either resolves it or moves it forward. Nobody has to notice the email.

The write-back is the part that keeps finance comfortable. Resolution does not mean a spreadsheet somewhere says the issue is closed. It means MRBR is released, or a credit memo request is created, or the PO is amended through the correct transaction, with the supporting evidence attached to the document and a full record of who decided what and when. The ERP remains the source of truth. The orchestration layer just made sure the truth arrived faster.

The Customer Loop in Practice

On the order-to-cash side, the same structure appears with the direction reversed.

Customer purchase orders arrive in whatever format the customer prefers. A large retailer sends EDI 850s that map cleanly. A mid-market distributor sends PDFs generated from their own system with your products described in their language. A long-standing account sends an email that says "same as last time, plus twenty of the blue ones." All three are valid orders. Only one of them creates a sales order without human intervention.

The work between the incoming document and a clean SAP sales order is interpretation. Mapping customer part numbers to material masters. Resolving ship-to locations that are described by store number rather than address. Catching pricing that contradicts the current condition record. Noticing that requested delivery dates are impossible given lead times, and flagging that before the order confirms rather than after the customer calls.

Credit blocks deserve their own mention because they are the clearest example of a correct system decision creating an incorrect business outcome. A sales order stops because exposure exceeds the limit. That is right. But the customer may have a payment in transit, a disputed invoice inflating the balance, or a limit that was set three years ago and never revisited. Resolving the block requires pulling the aging, checking for open disputes, confirming remittance status, and getting a credit manager to make a call. Every one of those steps is retrievable and assemblable in advance. The credit manager should receive a decision-ready package, not a notification that says a block exists.

Then there are deductions. A customer pays 96 percent of an invoice and provides a remittance code that means something inside their system and nothing inside yours. Someone has to figure out whether the deduction is a valid trade allowance, a pricing dispute, a shortage claim, or an error. Deduction research is close to pure investigation, which makes it one of the highest-value places to apply an agent that can read across contracts, prior claims, delivery documents, and the remittance itself.

The Approver Loop in Practice

Internal approvals are where cycle time hides in plain sight.

A purchase requisition sits in a release strategy. A journal entry waits on a controller. A vendor master change waits on a segregation-of-duties second signature. A capital request waits for a threshold approver who is traveling. In each case SAP is doing something reasonable, and in each case the delay is not caused by the decision itself but by the friction of getting the decision made.

Approvers are slow for predictable reasons. They receive requests without enough context to decide quickly, so they defer. They receive too many notifications, so they batch. They are unsure whether they are the right approver, so they ask. They approve in SAP GUI, which they open reluctantly.

Orchestration attacks each of those. Requests arrive with the context assembled, meaning the contract, the prior spend history, the budget position, and the reason for the request are all in one place. Reminders escalate on a defined cadence rather than depending on the requester's persistence. Delegation gets handled when someone is out rather than after the item has aged five days. And approval happens where the approver already is, which for most people means email or Teams rather than a transaction code.

The audit benefit is real and often underestimated. When approvals happen through side channels, which they constantly do, the system record shows a release without showing the reasoning. When the reasoning is captured as part of the approval flow and written back with the document, an auditor asking why a variance was accepted gets an answer instead of a shrug.

What Separates Orchestration From Workflow

Plenty of organizations already own a workflow tool, so the fair question is what makes this different.

Workflow moves an item from one inbox to another according to a defined path. It is excellent at that. It assumes the item is already understood, already classified, and already accompanied by whatever a human needs to act. Orchestration handles the part before routing, which is figuring out what the item actually is and what it needs.

Four capabilities mark the difference in practice.

The first is comprehension. The system has to read unstructured input, meaning invoices, statements, contracts, emails, remittance advices, and portal exports, and derive meaning rather than extract fields. A statement that lists nine invoices is only useful if the system can reconcile those nine against your open items and identify which one is missing.

The second is memory. A supplier who over-ships by 5 percent every quarter is a pattern. A customer who always deducts a specific allowance is a pattern. A cost center owner who approves within an hour on Tuesdays and never on Fridays is a pattern. Systems that treat each exception as a fresh event throw away the most valuable information they have.

The third is deterministic action. Reading and reasoning can be probabilistic. Writing to the ERP cannot. Every action that touches SAP should go through a defined interface, respect the same authorizations a human would, and produce the same document trail. The boundary between the flexible layer and the rigid layer needs to be explicit, and confidence thresholds need to determine what gets posted automatically versus what gets presented to a person with a recommendation attached.

The fourth is accountability. Every case needs an owner, a clock, and an escalation path. The reason exceptions age is almost never that nobody could solve them. It is that nobody was clearly responsible for solving them by a specific time.

The Numbers That Change

The measures that matter shift once the orchestration layer exists, and the shift itself is informative.

Touchless rate stops being the headline metric. It measures the easy population and says nothing about the hard one. A more honest pair of numbers is exception cycle time, meaning how long a stopped transaction stays stopped, and first-contact resolution rate, meaning how often a case closes without a second round of back-and-forth.

Cost per exception becomes visible for the first time in most organizations, because until the work is tracked it cannot be costed. Teams are usually surprised. The fully loaded cost of resolving a blocked invoice, once you count the emails, the internal chasing, the rework, and the eventual late payment fee or lost discount, tends to dwarf the cost of processing a clean one by an order of magnitude.

Working capital effects follow. Days payable and days sales outstanding both contain a component that is pure friction rather than policy. Early payment discounts get captured when invoices clear in time to capture them. Disputed receivables age less when disputes get researched in days rather than at month end.

And team composition changes. The people who were spending their mornings sorting queues and writing follow-up emails move toward supplier relationship work, contract compliance, and analysis of why exceptions occur in the first place. That last one produces compounding returns, because a properly instrumented exception layer tells you exactly which suppliers, customers, materials, and plants generate disproportionate friction. Fixing the root cause removes the exception permanently rather than resolving it faster.

Starting Where the Friction Actually Is

The instinct when approaching this is to scope a large program. That instinct is usually wrong, because the value concentrates in narrow places and the narrow places are identifiable within a week.

Pull the population of blocked documents from the last quarter and classify it by cause rather than by symptom. Almost every organization finds that a handful of causes account for a large majority of volume, and that the causes cluster by counterparty. One supplier generating 300 price variances a quarter is a different problem than 300 suppliers generating one each, and the two require opposite responses.

Then pick the single cause with the highest volume and the clearest resolution path, and orchestrate that end to end. Detection, classification, evidence gathering, counterparty conversation, decision, write-back, and case closure. Prove it moves cycle time. Then take the next one.

The reason this sequencing works is that the hard part of orchestration is not technology. It is agreeing on what "resolved" means for each exception type, who owns the decision, and what evidence is sufficient. Those agreements are easier to reach one exception type at a time, and once reached, they are reusable.

SAP will keep doing what it does well, which is holding the record and refusing to let bad data through. That refusal is a feature. What has been missing is a layer that treats each refusal as the start of a managed process rather than the arrival of another item in somebody's queue. The suppliers, the customers, and the approvers are not going away. The eleven days can.

If your team is spending more time chasing context than making decisions, that is the gap worth closing first. Artificio works with finance and supply chain teams to map exception populations inside SAP and build the orchestration layer around them, starting with the exceptions that cost the most and resist rules the hardest.