Testing SAP MM: Validating Procure-to-Pay Agents

A $48,000 purchase order goes out to a supplier on a Tuesday afternoon. Nobody approves it, and nobody notices. The goods arrive, the invoice matches, and the payment run pays it on time.

Months later, an auditor asks for the approval. There isn’t one. The SAP team goes looking for what broke and finds nothing broken. A reorganization had created a new purchasing group, and nobody added it to the release strategy. SAP searched for a strategy that matched the order, found none, and did exactly what it was designed to do: it treated the order as not needing approval.

That’s a composite, but many SAP MM consultants will recognize some version of it. It’s also the best way into SAP MM testing, because it shows the module’s defining habit. Procure-to-pay controls don’t fail loudly. They fail open.

That matters more now that agents work in procure-to-pay. SAP planned general availability of a Joule agent for SAP Ariba Intake Management in June 2026. SAP’s own community guides show Joule creating purchase requisitions in S/4HANA Cloud Private Edition, and machine learning already proposes next steps for GR/IR clean-up. Each of these fills in fields that P2P controls read, or helps resolve exceptions those controls raised.

This piece covers SAP procure-to-pay testing for that world: why P2P fails open, what the agents in it decide, five areas where assertions belong, and why the path an exception takes matters. (Still choosing tools? Start with our guide to SAP test automation.)

Procure-to-Pay Fails Open

Every core control in procure-to-pay works the same way. SAP compares a document against configuration and acts on what it finds. Approval routes are found by searching release strategies. Invoice variances are measured against tolerance limits. G/L accounts come from account determination. And differences that don’t match wait on the GR/IR account until someone clears them.

If you’ve read our piece on SAP SD testing, that will sound familiar. In SD, a price isn’t stored; it’s found. MM finds its controls the same way. What matters is what happens when the search comes back empty, or a setting says “don’t check”.

When configuration doesn’t cover a case, SAP doesn’t stop. The order goes out, the invoice posts, and the money moves.

None of this is a design flaw. Failing open keeps purchasing moving across configurations SAP can’t predict. But it changes what testing has to prove. A check that a PO “was released” passes for an order that never needed approval, and a check that an invoice “posted” passes for one accepted under “Do not check”. The useful assertion is one level down: which strategy, which tolerance, which account, and why.

What Procure-to-Pay Agents Actually Decide

“Agents in procurement” covers a lot of ground. In practice, the P2P decisions being automated fall into four groups, and each one touches a control from the table above.

• Intake and requisitioning. Turning a request from chat, email or Teams into a requisition: material or service, quantity, plant, purchasing group and account assignment. Control it touches: the release strategy, because the fields an intake agent fills are the fields approval routing reads.
• Purchase order creation and changes. Converting requisitions into orders, then changing quantities, prices and dates afterwards. Control it touches: what a change does to an order that’s already approved.
• Invoice capture and matching. Extracting reference numbers, amounts and tax from supplier invoices, then matching them to orders and goods receipts. Controls it touches: three-way match, tolerances and the duplicate check.
• Exception resolution. Releasing blocked invoices, requesting credit memos, adjusting PO prices and clearing GR/IR balances. Controls it touches: all of them.

The first and last groups deserve the most testing. For intake agents, a harmless-looking field choice (a different purchasing group, an order split in two) is also a routing choice. Exception agents decide that something which was stopped should go, and blocks exist because someone once decided a person should look. Our piece on where humans belong in agentic testing covers how to draw that line.

Invoice capture carries one more risk: a supplier invoice is text written outside your company, and an agent that reads it can be handed instructions. Our piece on indirect prompt injection in ERP covers that.

Five Areas SAP MM Testing Has to Cover

One rule runs through all five: assert the decision SAP made, not just the result on screen. The “where to check” notes point to the data that holds that decision.

1. Release strategies: test the route, not the approval

A release strategy is SAP’s approval routing for purchasing documents, found through classification: characteristics such as document type, purchasing group, plant and order value, matched against the values on each strategy. A PO marked “released” tells you little. Ask which strategy released it, and whether it should have been a different one.

• Every threshold, on both sides. If $25,000 is a boundary, test $24,999.99, $25,000.00 and $25,000.01, in every currency you buy in.
• Every new organizational value. New purchasing groups, plants, company codes and document types are the classic fail-open cause. If you rely on a catch-all strategy, test that it catches.
• Format traps. Characteristic values have to match SAP’s internal format. SAP’s own training notes that supplier 1010 must be maintained as 0000001010. Leave out the leading zeros and the strategy never matches.
• Overlaps. When two strategies match, SAP uses the first one it finds. Test documents in overlapping ranges and assert which strategy was picked.
• Changes after release. Raise a released PO’s value inside and outside the value-change tolerance on the release indicator, and assert whether a new approval started. Changing POs is routine agent work, so this one matters.
• Output before release. Blocked purchase orders can’t be output. Assert that nothing reached the supplier before final release.

Where to check: the release group, strategy, indicator and status fields on the PO header (EKKO-FRGGR, FRGSX, FRGKE and FRGZU). An order with an empty strategy field and a value above your lowest approval threshold is the opening story, caught in one query.

On flexible workflow, the mechanics differ but the tests don’t. The first active workflow that matches wins, so a broad one high in the list can capture orders meant for a stricter one. A PO that matches nothing is released automatically, and if the scenario-based workflow indicator is off for a document type, SAP falls back to the classic release strategy. Test the order of your workflows, not just their conditions.

If your auditors test P2P approvals as a key control, our SOX testing checklist for AI agents in ERP covers the evidence side.

2. Three-way match: test what matched to what

Three-way match compares the purchase order, the goods receipt and the invoice. With GR-based invoice verification on for a PO item, each partial delivery becomes its own invoice item, matched to a specific goods receipt in the PO history. With it off, the invoice is checked against the PO item as a whole.

• Partial deliveries. Three deliveries, one invoice. Assert that each invoice item references the right goods receipt, not just the right order.
• Invoice before goods receipt. Tolerance key DW decides what happens when the received quantity is zero. If your policy is to block, assert the block, and assert it lifts only when the goods arrive.
• Reversals after invoicing. Whether an invoiced goods receipt can be reversed or returned under GR-based verification is a Customizing setting. Test that yours holds.
• Duplicate invoices. SAP compares supplier, amount and currency, plus company code, reference and invoice date if they’re active as criteria. With reference active, the same invoice under a reformatted reference (INV-0042 versus INV0042) isn’t flagged, and that’s exactly the variation capture agents introduce.

Where to check: goods receipt and invoice quantities per item in the PO history (EKBE), and the goods receipt each invoice item references (RBKP and RSEG). For capture agents, compare the extracted reference with the source document too.

Invoices that arrive by EDI or from SAP Ariba add an interface in the middle. Our SAP integration testing guide covers that layer.

3. Tolerance keys: test both edges, and “Do not check”

Tolerance limits decide which invoice variances SAP accepts. They’re set per company code (transaction OMR6) under keys such as PP for price, DQ and DW for quantity, ST for dates, AN and AP for item amounts and BD for small differences. Each key has a lower and an upper limit, and this is what SAP does at each edge:

The last row catches people out. “Do not check” sounds like “skip this check”, but it means “accept everything”. SAP’s training warns that BD set to “Do not check” accepts all variances as small differences; to stop that, keep the check active and enter no limit.

• Each active key at its limit and one unit past it, per company code, including every new one.
• Every key set to “Do not check”, listed and justified by someone in finance.
• Supplier-specific tolerance groups, which override BD for small differences.
• The agent’s own posting limits. User tolerance groups set the maximum amount a user may post. An agent’s technical user should carry limits that match its delegated authority, not an administrator’s.

SAP’s own training on entering invoices with variances walks through each case. It’s worth sending to whoever owns your tolerance settings.

Where to check: the payment block on the invoice header (RBKP) and the blocking reasons on each item (RSEG).

4. GR/IR clearing: test what’s left behind

A goods receipt credits the GR/IR clearing account at the PO price, and the invoice debits it. When quantities or values don’t line up, the difference stays. Nothing errors. The balance just waits for period-end.

Clearing it is a judgement. SAP’s guidance is to confirm that no further receipts or invoices are expected for the PO item before maintaining the account, in MR11 or the Clear GR/IR Clearing Account app. That judgement increasingly gets machine help: the Reconcile GR/IR Accounts app tracks statuses such as Perform Write-Off, and a separately licensed machine learning service proposes the next step, priority and root cause for each item, based on past decisions.

• Every open item has a reason. Items above your threshold carry a root cause (differing quantity, missing goods receipt) and an owner.
• Write-offs need the facts. Before a write-off, assert that no open delivery or pending invoice exists for the PO item. If one arrives afterwards, the maintenance document should be cancelled (MR11SHOW), so test that path too.
• Proposals get checked against the record. If machine learning or an agent says “missing goods receipt”, check the PO history. Is the receipt missing, or was it posted against another item?

Where to check: goods receipt and invoice values per PO item in the PO history, and the GR/IR line items in the Universal Journal (ACDOCA). The FI side of those postings is covered in our SAP FI/CO agent testing piece.

5. Account determination: test where the money landed

Nobody codes the invoice for a stock material bought on a PO. Its G/L accounts come from configuration: the valuation class on the material master’s accounting view, the plant’s valuation grouping code, and the transaction keys each movement triggers, such as BSX for the stock posting, WRX for GR/IR clearing, GBB for offsetting entries and PRD for price differences.

A missing entry stops the posting with an error. That’s the good failure. The bad one is an entry that exists but points to the wrong account: the goods receipt posts, the invoice posts, and the value lands on the wrong balance-sheet line without a message.

• A matrix, not a sample. Each material type and valuation class, times the movements you use (goods receipt, issue to a cost center, scrapping, inventory difference), times each valuation grouping code. Assert the G/L account on every accounting line, by transaction key.
• Both price controls. At standard price, a price variance goes to the price difference account (PRD). At moving average, it can go to stock instead, depending on stock coverage. Test the same variance on one of each.
• New valuation classes and material types. Each one in a rollout gets the full matrix before go-live.
• Agent-created materials. If an agent creates material masters, the valuation class it picks decides which stock account every future receipt hits. SAP suggests one valuation class per account category reference; if yours allows several, test the agent’s choice.

SAP’s simulation in Configure Automatic Postings (OMWB) checks configuration, not the documents your business posts. Treat it as a design review, not a test.

Where to check: each accounting line carries its transaction key, so the assertion can be exact: this movement, this valuation class, this key, this G/L account.

Test the Path, Not Just the Outcome

Here’s a sequence where every step is allowed and the result is still wrong. The percentages are illustrative.

Every outcome check passes. The invoice matches the PO, nothing is blocked and GR/IR clears. Only a check on the path catches it: who changed the price, after which invoice, and with whose approval?

Every step was allowed. The supplier was still paid 6% more than anyone approved.

So for every invoice that was blocked and later released, record what removed the block. A later goods receipt or a supplier credit memo is expected. A PO price change made after the invoice arrived should need a person.

It’s also an access question. Authorization object M_RECH_SPG controls which blocking reasons a user can delete, but an agent that can change PO prices can make a block disappear without deleting anything. Our guide to SAP SoD testing covers what an agent’s access should and shouldn’t combine.

Where Sofy helps

Sofy’s AI agents for SAP testing cover this side of MM explicitly. The SAP product page lists procurement coverage for requisitions, purchase orders, goods receipts and invoice verification, and, on the Ariba side, supplier onboarding, sourcing events, purchase-to-pay flows and invoicing.

Two things on that page matter most for procure-to-pay. First, the agents read configuration, not just screens: metadata, custom fields, workflows, integrations and SAP configuration tables. Fiori apps are validated through business intent and OData rather than UI locators, and one test flow covers SAP GUI, Fiori, web and API layers. Release strategies, tolerance keys and account determination all live in configuration, so that’s where assertions need to point.

Second, the agents detect transports and upgrades and adapt to configuration changes. That’s how most MM risk arrives: a transport that adds a purchasing group, changes a tolerance or edits an account determination entry changes every later document, without anyone touching one. The page also claims cross-module intelligence across SD, FI and MM, which P2P needs, because an invoice that clears in MM posts in FI.

What Still Needs a Human

Two limits, stated plainly.

SAP procure-to-pay testing confirms that P2P behaves as configured. It can’t tell you whether the configuration is right: whether $25,000 is the right approval threshold, whether 5% is a sensible price tolerance, or whether a supplier deserves its own tolerance group. Those are policy decisions for procurement and finance, and a suite that passes on bad policy is still passing.

And the judgement calls stay human: writing off a GR/IR balance, disputing a supplier’s price, deciding whether a blocked invoice should be paid. Agents can propose. For anything that releases money or removes a control, a person should decide, with the evidence in front of them.

Frequently Asked Questions

What should SAP MM testing cover?

The controls that decide procure-to-pay outcomes: release strategies or flexible workflows, three-way match, invoice tolerance keys, GR/IR clearing and account determination through valuation class. For each one, assert the decision SAP made (which strategy, which tolerance, which G/L account), not just that a document was released or posted.

What happens if SAP finds no release strategy for a purchase order?

The purchase order isn’t subject to release, so it can be processed and sent without approval, and SAP shows no error. Common causes are new purchasing groups, plants or document types missing from the classification, and characteristic values in the wrong format. On flexible workflow, an unmatched PO is released automatically in a standard setup.

How do you test SAP invoice tolerance keys?

Per company code, test each active key at its limit and just beyond it, on both sides. Within the limits, SAP accepts the invoice silently; above the upper limit, it posts the invoice and blocks it for payment. Also list every key set to “Do not check”, which accepts every variance for that key.

Why does the GR/IR clearing account need testing?

Because differences between goods receipts and invoices don’t raise errors; they wait on the GR/IR account. Confirm that every open item has a root cause and an owner that write-offs happen only when nothing more is expected, and that machine-learning or agent proposals match the PO history.

How does valuation class affect account determination testing?

The valuation class on the material master, the plant’s valuation grouping code and the movement’s transaction keys (BSX, WRX, GBB, and PRD) decide which G/L accounts a receipt or invoice posts to. A missing entry stops the posting, but a wrong one posts silently, so test a matrix of materials, movements and plants.

How do you test AI agents in SAP procure-to-pay?

Agents shift SAP procure-to-pay testing towards inputs and exceptions, not just transactions. Intake agents fill the fields that route approvals, so assert the strategy each document got. Exception agent’s clear blocks, so record what removed each one: a later goods receipt is expected, but a PO price change after the invoice arrived should need a person.

The Bottom Line

Each module in this series has its own testing instinct. In FI/CO, you check that a posting landed correctly. In SD, you check that a price was found correctly. In MM, you check that a control actually ran, because when procure-to-pay configuration doesn’t cover a case, SAP doesn’t stop. It releases, accepts, parks or posts.

Agents sharpen that rather than change it. They fill the fields that route approvals and resolve the exceptions that hold payments. Test the route, the tolerance and the account, and for every exception, test the path it took to clear.