SAP Procurement Troubleshooting for Dummies: 10 Problems Buyers Actually Face

PR approved but no PO? Goods arrived but no GR? Invoice blocked again? Here is how procurement teams can trace the problem in SAP before sending another “please check” email.

Foto oleh Christin Hume di Unsplash

There is one stage in learning SAP that nobody really warns you about.

At first, you think the difficult part is remembering the T-Codes.

ME53N.

ME21N.

ME23N.

MIGO.

MIR4.

Then after working with procurement for a while, you realize something.

Knowing the T-Code is the easy part. Knowing why the transaction is stuck is the real skill.

You open SAP in the morning and find a PR that was approved two days ago but still has no PO.

Ten minutes later, a supplier emails:

“We still haven’t received the Purchase Order.”

Warehouse says the goods already arrived.

Finance says there is no Goods Receipt.

Then another supplier asks why their invoice is blocked.

Welcome to procurement troubleshooting.

The interesting part is that these problems rarely belong to one person. Procurement connects requester, buyer, approver, supplier, warehouse, service owner, and Accounts Payable.

So instead of memorizing another list of T-Codes, let us troubleshoot 10 problems buyers actually face.

For each case, we will answer four questions:

What happened? What should you check? Where should you check it in SAP? Who usually needs to take action?

1. The PR Is Approved, but There Is Still No PO

Monday morning.

A requester sends you a message:

“Hi, PR saya sudah approved dari Jumat. PO-nya sudah dibuat belum?”

You open the PR.

Yes, it is approved.

No, there is no PO.

This situation looks simple, but several things could be happening.

The PR may already be released but has not yet been assigned to a buyer. A source of supply may still be missing. Procurement may need to run sourcing first. There may already be a contract or Info Record that needs to be identified. The PR could also contain incomplete information that prevents the buyer from processing it confidently.

Approval only means the internal request has passed the relevant approval process. It does not automatically mean a Purchase Order exists.

What to check

Start with the PR itself.

Look at:

• Release or approval status
• Purchasing group
• Material and material group
• Quantity
• Delivery date
• Desired supplier
• Source of supply
• Account assignment
• Processing status
• Follow-on purchasing document

Then ask the most important question:

Has someone already created a PO against this PR?

Duplicate ordering is a much bigger problem than a slow PO.

Where to check in SAP

Use:

ME53N to inspect an individual PR.

ME5A when you need to review a larger PR population.

ME57 may be relevant when buyers need to assign and process Purchase Requisitions.

If your organization uses automatic PO creation for eligible requisitions, processes involving ME59N may also exist.

Who usually needs to take action?

Usually the buyer.

If information is incomplete, the requester may need to clarify the requirement.

If sourcing data is missing, procurement or purchasing master data teams may need to work on the source first.

The lesson is simple:

Approved PR does not equal completed procurement.

2. The PO Exists, but It’s Not Released

Good news.

You created the PO.

Bad news.

The supplier still cannot receive it because the document is waiting for approval.

This happens frequently in organizations that use PO release procedures or approval workflows.

A PO may require approval because of its value, purchasing organization, document type, category, or other configured conditions. SAP supports PO release procedures, including classic processing through transactions such as ME28 and ME29N. An unreleased PO may also be prevented from being output to the supplier depending on the configured process.

What to check

Open the PO and inspect:

• Release status
• Release strategy or workflow status
• Approval level
• Whether an approver is still pending
• Whether a recent PO change triggered another approval

That final point is easy to miss.

You may have had an approved PO yesterday.

Then someone changed the quantity, value, delivery date, or another relevant field.

Depending on configuration, that change may trigger the approval process again.

Where to check in SAP

Start with:

ME23N

For authorized approvers in classic release environments:

ME29N for individual PO release.

ME28 for collective PO release. SAP documents both as standard PO release transactions in applicable classic processes.

Who usually needs to take action?

The designated approver.

Procurement’s role is usually to identify the pending status and follow up with the correct person.

Do not immediately blame SAP.

Sometimes SAP is simply enforcing the approval process exactly as designed.

3. The PO Is Created, but the Supplier Says They Never Received It

This one is classic.

Buyer:

“The PO was created yesterday.”

Supplier:

“We didn’t receive anything.”

Buyer:

“But it’s already in SAP.”

Having a PO inside SAP and successfully communicating that PO to a supplier are two different events.

A document may exist and even be approved while its output has not been successfully processed.

What to check

First, confirm that you are looking at the correct PO.

Then check:

• PO release status
• Supplier information
• Output or message status
• Output medium
• Recipient information
• Whether the PO was successfully transmitted
• Whether a PO change generated new output

In classic SAP purchasing output, ME9F is used for Purchase Order output processing. SAP lists ME9F specifically for outputting Purchase Orders.

Where to check in SAP

Start with:

ME23N

Then, depending on your organization’s classic output configuration:

ME9F

Modern S/4HANA implementations may use different output management and Fiori-based processes, so do not assume every company sends POs through exactly the same route.

Who usually needs to take action?

Usually the buyer or procurement operations team.

If the output configuration itself is broken, SAP support or the functional team may need to investigate.

And before telling the supplier:

“Please check your spam folder.”

Make sure SAP actually sent something first.

4. The Goods Arrived, but There Is No GR in SAP

This is where physical reality and system reality stop matching.

The requester says:

“Barangnya sudah sampai dari kemarin.”

Supplier says:

“Delivered successfully.”

SAP says:

No Goods Receipt.

From a procurement perspective, the goods have arrived.

From a system perspective, they may still be outstanding.

That gap matters because Goods Receipt information can affect inventory, PO history, outstanding quantities, and invoice processing.

SAP supports Goods Receipt posting with reference to a Purchase Order through MIGO.

What to check

Open the PO.

Look at:

• Ordered quantity
• Delivered quantity
• PO History
• Goods Receipt documents
• Delivery status
• Whether a GR was posted and later reversed

Suppose the PO quantity is 100.

Warehouse received 100.

PO History shows no GR.

That usually means the operational process has not been recorded in SAP yet.

Another possibility exists.

A GR was posted, then reversed.

So do not only ask:

“Was GR ever posted?”

Also ask:

“What happened after it was posted?”

Where to check in SAP

Use:

ME23N to inspect PO History.

MIGO for authorized Goods Receipt processing.

MB51 can also help when you need broader material-document investigation in environments where the classic report is used.

Who usually needs to take action?

Normally the warehouse, receiving team, or authorized goods receiver.

Procurement should investigate and coordinate.

The buyer should not casually post a GR simply because a supplier says the shipment arrived.

A system receipt should reflect actual receipt.

5. The Quantities Do Not Match

Now things become more interesting.

PO:

100 units.

Goods Receipt:

80 units.

Supplier invoice:

100 units.

Someone asks:

“Why can’t we process this normally?”

Because SAP is seeing three different versions of reality.

Quantity variance in invoice verification occurs when the invoiced quantity differs from the quantity that remains open for invoicing.

What to check

Compare three numbers:

PO quantity

What did we order?

GR quantity

What did we actually receive?

Invoice quantity

What is the supplier charging us for?

Then understand the reason.

Maybe the supplier delivered only 80 and will send 20 later.

Maybe warehouse received 100 but posted only 80.

Maybe the vendor accidentally invoiced the full quantity.

Maybe part of the GR was reversed.

Do not fix a quantity mismatch before you know which number reflects reality.

Where to check in SAP

Use:

ME23N for PO quantity and PO History.

MIGO or material-document information for Goods Receipt investigation.

MIR4 for an already-posted invoice document.

Who usually needs to take action?

It depends on what is wrong.

If physical receipt is incorrect in SAP:

Warehouse or receiving team.

If the invoice quantity is wrong:

Supplier and Accounts Payable.

If the PO itself contains the wrong quantity:

Buyer and requester, subject to your organization’s change controls.

The buyer’s job is often not to fix all three documents personally.

It is to determine where the mismatch started.

6. The Supplier’s Invoice Price Does Not Match the PO

You negotiated:

IDR 1,000,000 per unit.

The PO says:

IDR 1,000,000.

The supplier invoice arrives at:

IDR 1,150,000.

Now Accounts Payable is asking procurement:

“Harga yang benar yang mana?”

This is one of those moments where procurement suddenly becomes very popular.

SAP defines a price variance in invoice verification when the invoiced price per unit differs from the relevant Purchase Order price basis.

What to check

Do not immediately change the PO to match the invoice.

First investigate:

• PO net price
• Price unit
• Currency
• Pricing conditions
• Freight
• Tax treatment where relevant
• Contract price
• Quotation
• Previous approved commercial agreement
• Whether the supplier invoice itself is incorrect

Maybe the buyer entered the wrong price.

Maybe the supplier ignored the agreed quotation.

Maybe the unit conversion is wrong.

Maybe the price is 1,000 per 100 units rather than 1,000 per unit.

Tiny field.

Huge difference.

Where to check in SAP

Use:

ME23N to inspect PO pricing and conditions.

MIR4 to inspect an existing invoice.

If a contract is involved:

ME33K

If Purchasing Info Record history is relevant:

ME13 or related purchasing information transactions.

Who usually needs to take action?

If the PO is incorrect:

Buyer, with the appropriate approval process.

If the supplier invoiced incorrectly:

Supplier, usually coordinated through buyer or AP.

If the commercial agreement itself is unclear:

Procurement or category owner.

A good buyer does not ask:

“How can we make SAP accept the invoice?”

A better question is:

“Which commercial value is actually correct?”

7. The Invoice Is Blocked

This is probably one of the most stressful emails procurement receives.

“Urgent. Vendor payment overdue. Invoice blocked. Please resolve.”

Suddenly everyone is copied.

Finance.

Requester.

Buyer.

Manager.

Sometimes even the supplier.

Invoices can be blocked when variances exceed configured tolerance limits or because another blocking condition exists. SAP uses MRBR for processing invoices blocked in Logistics Invoice Verification. SAP also notes that the blocking reason should be investigated, and a blocked invoice can only be automatically released when the blocking reason is no longer valid.

What to check

Start with the reason.

Possible areas include:

• Price variance
• Quantity variance
• Missing Goods Receipt
• Other tolerance issues
• Process-specific blocking conditions

Then trace the documents.

PO correct?

GR correct?

Invoice correct?

The invoice block is often a symptom, not the original problem.

Where to check in SAP

Use:

ME23N for PO and PO History.

MIR4 for invoice document investigation.

MRBR for authorized processing of blocked invoices.

Who usually needs to take action?

Usually several people.

Accounts Payable owns the invoice process.

Procurement investigates purchasing conditions.

Warehouse may need to correct GR information.

Supplier may need to issue a corrected invoice.

Releasing the block should come after the reason has been resolved.

Not before.

8. The Service Is Complete, but the SES Is Missing

Physical procurement has GR.

Service procurement has its own version of:

“Yes, we actually received what we paid for.”

Imagine your company hires a consultant for 20 working days.

The consultant completes the work.

The supplier submits an invoice.

Then Finance asks:

“Where is the Service Entry Sheet?”

Silence.

A Service Entry Sheet records actual performance of services by a service provider. SAP’s classic service procurement process uses ML81N for Service Entry Sheet processing, and acceptance may be immediate or connected to an approval procedure.

What to check

Review:

• Service PO
• Service quantity or value
• Whether SES has been created
• SES acceptance status
• Approval status
• Final entry status where relevant
• Whether the invoice refers to services that have actually been accepted

The important distinction is:

Supplier says the service is complete does not automatically mean the business has accepted the service.

Where to check in SAP

Classic environments may use:

ML81N for Service Entry Sheet processing.

ML85 may appear in collective SES release processes under relevant classic configurations. SAP documents ML81N and ML85 within service entry and release scenarios.

Who usually needs to take action?

Usually the service owner or requester must confirm that the service was actually performed.

Procurement may coordinate.

The approver may need to release the SES.

Accounts Payable can only work with the documents available in the process.

This is why:

“Vendor sudah selesai kok.”

is not enough.

SAP needs the transaction trail.

9. The Contract Has Expired

A new PR arrives.

Easy purchase.

Same supplier.

Same service.

You already have a contract.

You open it.

Validity end date:

Yesterday.

Now your five-minute PO suddenly becomes a sourcing issue.

Purchasing contracts are longer-term agreements used for subsequent purchasing activity, and their validity period is a core part of the agreement. SAP’s classic contract transactions include ME31K, ME32K, and ME33K.

What to check

Before using a contract, review:

• Validity start date
• Validity end date
• Supplier
• Material or service coverage
• Target value
• Target quantity
• Remaining agreement value or quantity
• Pricing conditions
• Whether an extension or replacement contract already exists

Expired contracts are not only an SAP inconvenience.

They are a procurement planning problem.

Someone should have seen the expiry coming.

Where to check in SAP

Use:

ME33K to inspect an individual contract.

For broader contract populations, ME3 family reports may be useful, such as:

ME3L by supplier.

ME3M by material.

Who usually needs to take action?

Usually the buyer, category manager, contract owner, or strategic sourcing team.

If the business still needs the goods or services, procurement must determine the correct commercial route.

Extend?

Renegotiate?

Run sourcing?

Use another valid agreement?

The answer depends on procurement policy.

What you should not do is pretend the expiry date does not exist.

10. The PO Is Still Open Months Later

This is the procurement equivalent of finding something strange at the back of your refrigerator.

You run an open PO report.

There it is.

PO created:

Eight months ago.

Delivery date:

Six months ago.

Remaining quantity:

2 units.

Nobody seems to know what happened.

Welcome to PO cleanup.

A Purchase Order can remain operationally open when an outstanding quantity or process step still exists. SAP’s PO transactions include status information and PO History, and the PO item data includes a Delivery Completed indicator for relevant scenarios.

What to check

Do not close it immediately just because it looks old.

Investigate:

• Original PO quantity
• Received quantity
• Remaining quantity
• Invoice quantity
• PO History
• Reversals
• Delivery status
• Invoice status
• Whether the supplier will still deliver
• Whether the business still needs the remaining quantity
• Delivery Completed indicator
• Final Invoice indicator where relevant
• Service completion status for service POs

Example:

PO quantity:

Received:

Remaining:

The supplier confirms no further delivery will happen.

Now procurement needs to follow the organization’s process for closing the outstanding commitment correctly.

Another example:

PO quantity:

Received:

Invoice:

That is a different problem.

Closing should reflect the actual business situation.

Where to check in SAP

Start with:

ME23N

This is where PO status and Purchase Order History become extremely valuable.

For larger populations:

ME2N, ME2L, or relevant purchasing reports can help identify old or outstanding purchasing documents.

Who usually needs to take action?

Potentially:

Buyer

to manage the PO.

Requester

to confirm whether the remaining requirement still exists.

Warehouse

to clarify receipt status.

Accounts Payable

to clarify invoice status.

Supplier

to confirm whether additional delivery or invoicing will happen.

An old PO is not automatically a bad PO.

An old PO that nobody understands is the real problem.

The Troubleshooting Habit That Makes SAP Much Easier

After dealing with enough procurement issues, you start noticing a pattern.

Most problems can be investigated using four questions:

1. What did we request?

Start with the PR.

2. What did we order?

Check the PO.

3. What did we actually receive?

Check GR or SES.

4. What did the supplier invoice?

Check the invoice.

Then compare them.

That is the heart of procurement troubleshooting.

You do not need to randomly jump between 20 transactions.

You need to understand the document flow.

The 10-Problem SAP Procurement Cheat Sheet

If you only remember one section from this article, save this:

PR approved, no PO Check: ME53N, ME5A, sourcing status

PO created, not released Check: ME23N Release process: ME29N / ME28

Supplier did not receive PO Check: ME23N Classic output: ME9F

Goods arrived, no GR Check PO History: ME23N GR processing: MIGO

Quantity mismatch Compare: PO vs GR vs Invoice Check: ME23N, material document, MIR4

Price mismatch Compare: PO price vs supplier invoice Check: ME23N, MIR4

Invoice blocked Investigate: MIR4 Blocked invoice processing: MRBR

SES missing Check or process service entry: ML81N

Contract expired Check: ME33K Broader search: ME3 reports

PO still open months later Start with: ME23N Then investigate outstanding GR, invoice, quantity, or service activity.

That is a much more useful way to remember SAP than memorizing T-Codes alphabetically.

SAP Troubleshooting Is Mostly About Asking Better Questions

One thing working with procurement systems teaches you quickly is that SAP rarely tells the full story in one screen.

A supplier says:

“We delivered.”

SAP asks:

Was the GR posted?

A requester says:

“The service is complete.”

SAP asks:

Where is the SES?

A buyer says:

“I already created the PO.”

SAP asks:

Was it released and output?

Finance says:

“The invoice is blocked.”

Procurement should ask:

What caused the block?

This is where procurement professionals become more valuable.

The job is no longer just:

“Create the PO.”

It becomes:

“Understand why the process stopped and identify what needs to happen next.”

And sometimes the answer is procurement.

Sometimes warehouse.

Sometimes Accounts Payable.

Sometimes the requester.

Sometimes the supplier.

The best buyer is not the person who tries to fix everything alone.

It is the person who can open SAP, follow the documents, identify the broken link, and get the right person to fix it.

That is when SAP stops feeling like a complicated ERP full of strange codes.

It starts becoming what it was designed to be:

a record of what actually happened in the procurement process.

~ Wildan Bagus Maulana | Life-Jouney & Career (@wildannbm)