Your SAP payment IDoc is green (status 03) — and the bank never received it

The payment run completed. In WE02 the outbound payment IDoc — PAYEXT — shows status 03, displayed in green, no errors anywhere. Accounts payable tells the vendor the money is on its way. Three days later the vendor has not been paid, and the bank has no record of the file at all.

Nothing in that story involves a broken IDoc. It involves a misunderstanding of what status 03 certifies — and it is one of the most common false assurances in SAP payment operations.

What status 03 actually proves

Follow the outbound status chain. Status 01: the IDoc was created. Status 30: it is ready for dispatch. Status 03: data passed to port OK. That is the whole claim. SAP assembled the IDoc and handed it to the port defined for the partner — a file port, a tRFC port, a pipeline toward middleware. From the ALE layer’s point of view, its job is finished, and WE02 turns green and stays green forever.

What status 03 says nothing about: whether the RFC destination behind the port connected, whether a file was written where the bank channel or middleware actually picks files up, or whether the bank received — let alone accepted — anything. The real-world journey of the payment starts where the green status ends.

Where it silently breaks

Two failure points account for most cases:

• The tRFC call behind the port fails. The IDoc is passed to the port, the transactional RFC that carries it onward errors out — destination unreachable, authorisation expired, target down — and the failed call sits in SM58 (transactional RFC queue). Nobody monitors SM58 in most organisations, so the entry waits there while WE02 shows green and the payment ages.
• The file lands somewhere nobody scans. With a file port, the IDoc’s payload is written to a directory. After a system copy, a folder restructure, or a middleware change, that directory is no longer the one the pickup job reads. The file exists. The IDoc is green. The bank channel sees nothing.

In both cases the breakage is downstream of the IDoc layer — which is exactly why checking the IDoc layer harder never finds it.

The three checks that prove receipt, not just dispatch

1. SM58, around the dispatch time. Look for a stuck or failed tRFC entry for the destination in question. A failed entry there is the payment, still inside your own landscape.
2. The file itself. Confirm the outbound file exists in the location the bank channel or middleware picks up from — not merely that the IDoc exists in SAP. If your flow includes middleware, confirm it received and forwarded the file; each hop has its own log.
3. The bank-side acknowledgement. Look for the status feedback or acknowledgement for that payment. No acknowledgement means no assumption of payment — “we sent it” is not evidence the bank has it.

Only when all three are clean is “the bank has it” a statement you can make to a vendor.

The reprocessing trap

The instinctive fix is also the dangerous one: re-dispatch the IDoc, or rebuild it with WE19, and watch it go green again. Stop first. If the original file was in fact picked up late — by a restarted job, a manual middleware retry — a blind resend puts two copies of the same payment into the channel, and the vendor gets paid twice. Recovering a duplicate payment is a longer conversation than a late one.

The safe order is: establish whether the original file left your landscape, establish whether the bank processed it, and only then reprocess — through BD87 for the failed IDoc where that applies, or by clearing the SM58 failure and letting the original call complete. Document which copy is the live one, so the next person does not “fix” it again.

Going further

Aumtech Solutions’ course SAP IDoc Training is a short, focused starter on exactly this skill set — reading IDoc statuses for what they actually prove, where SM58, WE02, BD87 and WE19 each fit, and how to reprocess without duplicating a payment — for $21: https://www.aumtechsolutions.com/courses/sap-idoc-training/

Not sure how exposed your own interfaces are? The free SAP Treasury Health Check scores your processes across treasury, payments, and bank statements in about 20 minutes — including whether failed interfaces alert the right owner or are found by accident: https://www.aumtechsolutions.com/treasury-health-check/