SAP IDoc Reprocessing Runbook Template
Reprocessing IDocs is simple when one expert does it and risky when it is passed around. This runbook template gives support staff a repeatable procedure for one interface, including limits, approvals and what not to do.
Fill in
SAP IDoc Reprocessing Runbook Template
Runbook: Customer orders (ORDERS05)
Interface ID: IF-001 Direction: Inbound Message type: ORDERS Last reviewed: 2026-10-20
Scope
This runbook covers IDocs for Customer orders (ORDERS05) in failure statuses 51, 56. Target time to recover is 4 business hours. Bulk reprocessing above 500 IDocs in one run needs approval from Order to cash lead.
Procedure
| Step | Action | Tool | Check |
|---|---|---|---|
| 1 | List failed IDocs for message type ORDERS | WE02 or BD87 | Count and group by error text |
| 2 | Identify the root cause from the status record | WE02 | One cause per group |
| 3 | Correct master data or configuration | Functional team | Fix confirmed in the target client |
| 4 | Reprocess a single IDoc as a test | BD87 | Status changes to success |
| 5 | Reprocess the remaining IDocs in batches | BD87 | No more than 500 per run |
| 6 | Confirm documents were created or sent | Business transaction | Document numbers match |
| 7 | Record the outcome in the ticket | Service desk | Count, cause, fix |
Do not do
Do not reprocess IDocs before the root cause is fixed. Do not change the IDoc data in WE02 without recording the change in the ticket. Do not delete IDocs to clear a monitor. Do not resend outbound IDocs that the partner may already have received without checking with them first.
Escalation
If reprocessing fails with the same error after the fix, or if more than the usual number of IDocs fail within an hour, escalate to SAP integration on-call.
Approval
BD87 is the usual status monitor for inbound and outbound IDocs. RBDMANI2 reprocesses inbound IDocs with errors and RBDAGAIN resends certain failed outbound IDocs. Test the exact programs in your release and client before relying on this runbook.
Interface support runbook pack
Ask for a review of your runbooks against the failure statuses you see most often.
Optional. The tool and every export work without this. No spam.
How to use the runbook template
Create one runbook per interface or per message type. Fill the scope fields, choose the reprocessing method and name the approver and escalation contact. Export the document and store it where the support team works, usually the service desk knowledge base. The procedure table is intentionally short: select, diagnose, fix, test with one IDoc, reprocess the rest, verify the business document and record the result. Adjust the steps to match local tools, such as a middleware replay for IDocs that originate in an external system.
- One runbook per interface
- Name a real approver for bulk runs
- Review at least once a year
Choosing the reprocessing method
BD87 lets you select IDocs by status, message type and date and then process them in the foreground or background. It works for most inbound failures. Program RBDMANI2 can force reprocessing of inbound IDocs in selected statuses, which is useful for scheduled jobs. For outbound IDocs that never reached the port, RBDAGAIN can resend those in statuses such as 02, 04 and 05. WE19 is the test tool and is better suited to a single IDoc whose data you want to edit and copy than to mass recovery. For IDocs originating outside SAP, the better fix is often to replay from the middleware.
Risks to control
The main risk is duplicate or partial processing. Posting the same order twice, resending a shipment notice a customer already acted on, or reprocessing in the wrong client all cause real damage. That is why the template forces a test of one IDoc, a batch limit and a business check. For outbound resends, confirm with the partner that the first message was not received. For inbound, confirm the application document does not already exist. Write the duplicate check for your interface into the Check column.
- Test one IDoc before the batch
- Check for duplicate documents
- Keep an audit trail in the ticket
Frequently Asked Questions
What is the difference between BD87 and RBDMANI2?
BD87 is an interactive status monitor where you select and process IDocs. RBDMANI2 is a report that reprocesses inbound IDocs with errors and can be scheduled as a job. Both end up calling the same posting logic.
Can I reprocess an IDoc that is in status 53?
No. Status 53 means the application document was posted successfully. Reprocessing would risk a duplicate, so the standard tools do not offer it for that status.
How do I resend an outbound IDoc?
For IDocs that failed to reach the port, use RBDAGAIN or BD87 to dispatch again. For IDocs already delivered where the partner needs a new copy, create a new IDoc from the application document, for example by message control output repeat.
Who should approve bulk reprocessing?
The business owner of the process, such as the order to cash lead for sales orders. They understand the cost of a duplicate. Agree the batch limit in the runbook.
Netray can add a read-only monitor that groups failed IDocs by root cause and proposes the matching runbook step, with a human approving every reprocess.
Related Tools
SAP IDoc Error Incident Ticket Template
A structured ticket for IDoc failures: control record details, status history, root cause, fix and prevention actions.
SAPSAP IDoc Backlog Clearance Time Calculator
Work out how many hours a backlog of unprocessed IDocs will take to drain, based on throughput per job, parallel jobs and new IDocs still arriving.
SAPSAP IDoc Partner Profile (WE20) Setup Template
A fill-in setup sheet for WE20 partner profiles, WE21 ports and the inbound and outbound parameters behind each IDoc partner.
SAPSAP Integration Test Case Matrix Worksheet
An editable test matrix for SAP interface testing, with scenario, expected result, pass flag and defect count rolled up to a pass rate.