What a Two-Week SAP Invoice Automation Pilot Looks Like, Day by Day

The AP manager at a mid-sized manufacturer told us something that stuck. She had sat through four vendor demos in six weeks. Every one of them showed a beautiful invoice sliding into a screen, fields lighting up green, a posting confirmation appearing in what looked like SAP. Every one of them ended with the same line about a "quick proof of concept, maybe six to eight weeks."

Six to eight weeks. For a proof of concept. Her actual question was simpler than that. Can this thing read the 340 supplier invoices that hit her shared mailbox every week, match them against purchase orders in ECC, and park them without an AP clerk retyping the line items? She did not need a program. She needed an answer.

That gap between what buyers want to know and what vendors propose is where most SAP automation evaluations die. The pilot balloons into a mini-implementation, the scope creeps into workflow redesign, and four months later somebody in finance asks why they are paying for a project that has not processed a single production invoice. The alternative is a tightly scoped two-week pilot with a written decision gate at the end. Ten business days, real invoices, a real SAP connection, and a scorecard that says go or no go.

Here is what those ten days actually look like when the pilot is run properly, what each side has to bring, and where the whole thing falls apart if you are not careful.

Why most SAP pilots fail to decide anything

A pilot has exactly one job. It has to reduce uncertainty about a purchase decision. Anything that does not reduce uncertainty is decoration.

Most pilots fail this test in one of three ways. The first is the sanitized sample problem. Somebody sends the vendor twenty clean PDF invoices from the top three suppliers, all in one currency, all PO-based, all with legible line tables. The extraction accuracy comes back at 98 percent and nobody learns anything, because the messy 30 percent of the invoice population was never tested. Scanned faxes from a small parts supplier in Ohio. Handwritten delivery note references. Credit memos that reverse three separate line items across two purchase orders. Those are the documents that decide whether automation works.

The second failure is the disconnected demo. The vendor runs extraction in their own cloud and shows a screen with SAP-looking fields. No connection to your ECC or S/4HANA system, no supplier master lookup against LFA1, no purchase order read from EKKO and EKPO, no tolerance check. Extraction accuracy is the easy half of the problem. The hard half is whether the extracted values survive contact with your master data and your posting rules.

The third failure is the missing decision gate. The pilot ends, everyone agrees it was interesting, and the conversation moves to a follow-up workshop. Nobody wrote down beforehand what result would trigger a purchase and what result would trigger a walk-away. Without that, the pilot is a demo with extra steps.

A two-week structure fixes all three, but only because the compression forces discipline. Ten days does not leave room for a custom development sprint or a workflow redesign. It leaves room to answer the question.

What gets locked before Day 1

The pilot starts before the pilot starts. Roughly a week of light preparation determines whether Day 1 is productive or wasted on scheduling.

Four things need to be settled in writing. Scope comes first. Pick one company code, one or two plants, and a defined set of invoice types. For a first pilot the sensible scope is PO-based invoices plus credit memos, with non-PO invoices treated as a stretch goal. Adding a second company code adds tax logic, currency handling, and a second set of tolerance keys, which turns a two-week test into a four-week one.

Second, the sample pack. You want between 300 and 500 historical invoices pulled from a real date range, not hand-picked. The right way to build this is to take every invoice received in a specific two-week window from the previous quarter and export it whole. That gives you the natural mix of good scans, bad scans, PDFs, emails with the invoice in the body, and the occasional supplier who still faxes. Include the corresponding SAP postings for those invoices, because that becomes the ground truth for measuring accuracy.

Third, system access. This is the item that quietly kills timelines. Getting a service user provisioned in your QA or sandbox environment involves Basis, security, and often a change request. Start it two weeks early. What the pilot needs is read access to purchase orders, goods receipts, and supplier master data, plus authorization to park supplier invoices. Not post. Park. A parked document in MIR7 can be reviewed by a human and deleted without any financial impact, which makes it the correct pilot output.

Fourth, success criteria. Write down the numbers before you see any results. Something like: 90 percent field-level accuracy on header data, 85 percent on line items, 60 percent of PO invoices requiring zero human touches, and every exception routed to a named owner within the system. Sign it. The value of writing it early is that nobody gets to move the goalposts on Day 10 in either direction.

Total preparation effort on the customer side runs about six to eight hours across those four items. The pilot itself asks for roughly two to four hours a week from the AP lead, an hour or two from a functional MM or FI consultant, and a single half-day from Basis.

Week one, day by day

Day 1: Kickoff and scope lock

Ninety minutes, not a full day. The agenda covers who does what, what is in scope, and what is explicitly out. The most useful part of this meeting is the exclusion list, because it is where hidden expectations surface. Somebody will ask about intercompany invoices. Somebody else will mention the freight invoices that come in as spreadsheets. Both are legitimate future requirements and both belong outside a ten-day test.

The other Day 1 output is the exception taxonomy. Before any invoice gets processed, both sides agree on what counts as an exception. Missing PO number. PO closed. Quantity variance beyond tolerance. Price variance beyond tolerance. Supplier not found in master data. Tax code mismatch. Duplicate invoice suspicion. Six or seven named categories, each with an owner. This taxonomy becomes the spine of the final scorecard, because the interesting question is never "did it work" but "what happened when it did not."

Day 2: Sample ingestion and cold baseline

The 400-invoice sample goes in with no configuration, no templates, and no tuning. This produces the cold baseline, and it is the single most honest number in the entire pilot.

Why run it cold? Because every vendor can hit high accuracy after being handed a labeled training set. What you want to know is how the system performs on suppliers it has never seen, since that is what production looks like when a new vendor onboards on a Tuesday afternoon. A modern extraction model working from document structure rather than positional templates should land somewhere in the high eighties on header fields cold, and lower on line items. If the cold baseline comes back at 60 percent, no amount of tuning in the remaining eight days will save it.

The baseline report breaks accuracy down by field rather than reporting a single blended number. Invoice number, invoice date, supplier identity, gross amount, tax amount, currency, PO reference, and line-level quantity, unit price, and description. A single blended accuracy figure hides the fact that a system might read amounts perfectly and fail on PO numbers, which would make it useless for three-way matching.

Day 3: Field mapping and SAP structure alignment

Now the extracted values get mapped to actual SAP fields. This is unglamorous work and it is where the pilot earns its credibility with the finance team.

Invoice number maps to XBLNR, the reference field, with your organization's truncation rules applied since XBLNR has a sixteen-character limit and plenty of suppliers issue longer numbers. Invoice date maps to BLDAT and posting date derives from your rules rather than from the document. Currency maps to WAERS. Company code and the vendor account come from the supplier match. Line items map into the item structure with quantity, unit of measure, and net amount, and the PO reference splits into EBELN and EBELP so each invoice line lands against the correct purchase order item.

Two decisions usually come up on Day 3. The first is unit of measure conversion, because suppliers invoice in cases while your PO is in eaches more often than anyone expects. The second is tax handling, where the extracted tax amount has to reconcile against the tax code on the purchase order rather than simply being copied from the document face.

Day 4: Supplier identification and master data matching

Extraction gives you a supplier name and probably a tax identification number. SAP needs a vendor account number. Bridging that gap correctly is what separates a document reader from an AP automation system.

Good matching runs a cascade. Tax identification number first, since it is the strongest signal. Then bank account details, which also doubles as a fraud control when the invoice bank details do not match the vendor master. Then fuzzy name matching against LFA1 with normalization for legal suffixes, punctuation, and the fact that "Northern Composites Ltd" and "NORTHERN COMPOSITES LIMITED" are the same company. Then supplier-specific document layout, which catches repeat vendors reliably.

Day 4 is also when the duplicate check gets configured. The standard SAP duplicate logic on vendor, reference, amount, and date is a reasonable floor, but pilots regularly surface the near-duplicate case where a supplier reissues an invoice with a new number after a dispute. Flagging that pattern is worth real money and it is a good thing to test explicitly.

Day 5: Week one checkpoint

Forty-five minutes with the numbers on screen. Not a status update. A review of measured accuracy by field, by supplier, and by document quality band.

The useful output of Day 5 is a segmentation of the invoice population into three buckets. The clean bucket, which is typically 60 to 70 percent of volume, processes correctly with no intervention. The recoverable bucket needs one specific fix, usually a mapping rule or a supplier master correction. The hard bucket, which is often 5 to 10 percent, contains documents that will always need a human, such as invoices referencing purchase orders that do not exist yet or handwritten annotations that change the amount payable.

That third bucket matters more than people expect. A pilot that pretends every invoice can be automated sets up a production rollout that disappoints. A pilot that says "these 8 percent will always touch a human, here is why, and here is how they get routed" is telling the truth and builds a business case that survives contact with reality.

Week two, day by day

Day 6: SAP connection and read-back

Week two is where the pilot stops being a document exercise and becomes an SAP exercise.

The connection goes into a QA or sandbox system, never production. For S/4HANA the usual route is the OData service for supplier invoice processing, exposed through the gateway. For ECC the route is typically RFC-enabled function modules, with BAPI_INCOMINGINVOICE_PARK doing the actual parking work and BAPI_PO_GETDETAIL retrieving the purchase order structure. Some environments prefer an IDoc-based approach using INVOIC02, which works fine for high volume but gives slower feedback during a pilot because errors surface in the IDoc monitor rather than immediately.

Whatever the transport, Day 6 has a narrow goal. Read a purchase order out of SAP, read the goods receipts against it, and display them next to the extracted invoice on a single screen. That side-by-side view is the moment the AP team usually leans forward, because it is the first time they see the comparison they currently do by alt-tabbing between a PDF and ME23N.

Basis involvement on Day 6 is normally two hours. Service user, authorization object check, network path, and a connectivity test.

Day 7: Three-way match and tolerance logic

The core of the whole thing. Invoice against purchase order against goods receipt.

Matching sounds binary and is not. Real matching has to handle partial goods receipts where the invoice covers three of five delivered items, over-delivery inside the allowed tolerance, price variances that fall within the tolerance keys configured in your system, unplanned delivery costs that appear on the invoice but not on the PO, and multi-PO invoices where a single document spans several purchase orders.

The pilot configuration mirrors your existing tolerance setup rather than inventing new rules. If your quantity tolerance is 5 percent and your price tolerance is 2 percent or 50 euros, whichever is lower, the pilot uses exactly those. The point is not to test whether tolerances work in SAP. They already do. The point is to test whether the automation reaches the same verdict a human clerk would reach, using the same rules.

At the end of Day 7 you should be able to run the full 400-invoice sample end to end and see a first-pass match rate. That number, more than extraction accuracy, is what predicts how much labor the system actually removes.

Day 8: Exceptions, routing, and approvals

Every invoice that does not match cleanly needs somewhere to go. Day 8 builds the routing.

Each exception category from Day 1 gets an owner and a path. Quantity variance routes to the goods receipt owner at the receiving plant. Price variance routes to the buyer who created the purchase order, pulled directly from the PO header rather than from a static list. Missing PO routes back to the requester. Supplier not found routes to master data governance. Duplicate suspicion routes to the AP supervisor with both documents displayed together.

Two design questions come up here and both deserve deliberate answers. First, does the exception get resolved in the automation layer or inside SAP? For organizations already running a workflow tool, resolving inside the existing tool avoids a second inbox. For organizations doing this manually today, resolving in the automation layer with a parked SAP document is usually faster. Second, what happens to an exception nobody touches? Aging rules and escalation are unglamorous and they are the difference between a system that runs itself and one that quietly accumulates a backlog.

Day 9: Live shadow run

The most valuable day of the ten. For one full working day, every invoice arriving in the AP mailbox goes through both the automation and the normal manual process in parallel.

Nothing gets posted from the automation side. Documents get parked in the sandbox and compared against what the AP team did in production. Every disagreement gets logged with a reason. Sometimes the system is wrong. Sometimes, and this is more common than teams expect, the system is right and the manual process made an error, usually a transposed amount or a cost centre assignment that does not match the purchase order.

Shadow running matters because the historical sample has a subtle bias. Historical invoices were already processed successfully, which means they are survivors. The live day includes the invoices that would have bounced, the supplier who changed their template last month, and the email with the invoice attached as an image inside a Word document. That is the real population.

Volume on a shadow day is usually 40 to 80 invoices. Enough to be representative, small enough to review in detail.

Day 10: Readout and decision gate

Two hours with the people who can sign. The readout follows the success criteria written before Day 1, not a narrative.

The deliverable pack includes the measured scorecard against each stated target, the exception distribution with volumes per category, the shadow run comparison with every disagreement explained, a labor model translating touch rates into hours and cost per invoice, an architecture note describing exactly how the production connection would work, and a production plan with dates and dependencies.

The last item deserves emphasis. If the pilot succeeds, the very next question from the CFO is "when does this go live and what does it cost to get there." Having that answer ready on Day 10 removes weeks of drift. A realistic production path after a clean pilot is four to six weeks to a first live company code, dominated by security review and change management rather than by technology.

The scorecard that actually decides it

Six numbers carry the decision. Everything else is supporting detail.

Field-level extraction accuracy, measured separately for header and line items, tells you whether the reading works. Header accuracy above 95 percent and line accuracy above 90 percent after a week of tuning are reasonable expectations for a mature system on a mixed sample.

First-pass match rate tells you whether the SAP logic works. This is the percentage of PO-based invoices that clear three-way matching with no human involvement. Between 65 and 80 percent is a healthy range for a first pilot. Anything above 85 percent usually means the sample was too clean.

Touch rate is the inverse view and the one finance understands fastest. Out of 100 invoices, how many did a person open? Going from 100 to roughly 30 is where the labor savings live. 

Exception resolution time measures whether the routing works. If exceptions still take four days to resolve, the automation moved the bottleneck rather than removing it. 

Duplicate and fraud catch rate is the risk metric. Seed a handful of known duplicates and one invoice with mismatched bank details into the sample and see whether the system flags them. Teams skip this and later regret it. 

Cost per invoice ties it together. Take the fully loaded AP cost today, apply the measured touch rate, and produce the projected figure. A credible model shows the arithmetic rather than quoting an industry benchmark. 

Where two-week pilots go sideways 

Access delays cause more failed pilots than technology does. If the sandbox user is not ready on Day 6, the second week compresses into three days and the shadow run gets cut, which removes the most informative test. 

Scope drift is the second killer. Somebody sees the Day 7 matching screen and asks whether it could also handle service entry sheets, or contract invoices, or the freight spreadsheets. Every one of those is a reasonable production requirement and none of them belongs in the ten days. Keep a parking list, revisit it after the decision. 

Sample bias is the third. The team sending the invoices naturally wants the pilot to succeed and unconsciously curates. The defence is mechanical selection by date range with no filtering, agreed on Day 1. 

The fourth is the absent decision maker. Pilots run by an AP team without a finance sponsor produce good results and no purchase, because the person who signs never saw the shadow run and receives a summary slide six weeks later. Get the sponsor into the Day 5 checkpoint and the Day 10 readout as a condition of starting. 

After Day 10 

A pilot that ends with a clear no is a good outcome. Two weeks and about twenty-five internal hours is a cheap way to find out that your invoice population is too unusual, or that the integration path does not fit your landscape, or that the savings do not justify the change management effort. That is a real answer, delivered fast. 

A pilot that ends with a yes hands you something more useful than a signature. It hands you a measured baseline, a working field map, a tested exception taxonomy, and a routing design that has already survived a live day. Production rollout becomes a matter of moving a proven configuration from sandbox to a controlled live environment, extending it company code by company code, and letting the touch rate settle over the first two months as supplier coverage widens. 

The invoices keep arriving either way. Three hundred and forty a week, every week, whether the decision gets made in ten days or ten months. Compressing the evaluation is not about rushing the choice. It is about refusing to let the choice stay open while the work piles up. 

If you are running an SAP landscape and weighing invoice automation, the question to bring to your next vendor conversation is simple. Show me the ten days.