BD87 — IDoc Reprocessing
BD87 reprocesses failed or waiting IDocs after the underlying application, master-data, configuration, or communication cause has been corrected. Use it for recoverable IDoc statuses, review a small sample first, and confirm that reprocessing is safe and will not create duplicate business documents before running a larger population.
This practitioner page covers BD87, IDoc Reprocessing. It explains the transaction's operational purpose, the evidence to capture, the data or configuration objects that matter, and the failure patterns that commonly mislead SAP support teams.
Published 20 Sept 2026· 691 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
Purpose
reprocess failed or waiting IDocs after the underlying business, master-data or configuration cause has been corrected. The useful way to think about BD87 is as part of an end-to-end business or technical flow, not as an isolated screen. Capture the exact organizational context, business object, user and timestamp before drawing conclusions, because those values determine which data and configuration the transaction reads.
When it is used
BD87 is typically used when inbound or outbound IDocs are in a recoverable error status and need application processing to run again. It is also valuable during test cycles because it provides a repeatable way to prove what SAP processed, selected or rejected. In production, narrow the selection to the affected population first and separate diagnostic/display actions from functions that can post, retry, clear or change system state.
How to use it in practice
- Filter the worklist to the exact failed population and inspect representative errors first.
- Correct the root cause before choosing Process; BD87 is not a repair mechanism by itself.
- Reprocess a small sample before running a large population.
- Review the resulting status and created/changed application documents.
- For mass recovery, reconcile counts so every intended IDoc either succeeded or remains explicitly unresolved.
Key data objects
These are the strongest anchors for a BD87 investigation. Record the values in the incident or test evidence so another consultant can reproduce the same conclusion and distinguish master data, configuration, authorization and transaction-state problems.
- IDoc status — verify the exact value, organizational context and relationship to the affected document or interface.
- message type — verify the exact value, organizational context and relationship to the affected document or interface.
- partner — verify the exact value, organizational context and relationship to the affected document or interface.
- error text — verify the exact value, organizational context and relationship to the affected document or interface.
- reprocessing result — verify the exact value, organizational context and relationship to the affected document or interface.
How to prove it in the data
Use a three-part proof: first establish the source document or request and its exact keys; second show the status, accounting/interface record or runtime evidence produced by SAP; third show the corrected result using the same selection. Cross-check neighboring transactions and logs rather than relying on a single screen message. This prevents a successful retry, changed selection or unrelated master-data edit from being mistaken for the real fix.
ECC vs S/4HANA
BD87 remains standard for many ALE/IDoc recovery scenarios on S/4HANA. Integration modernization does not eliminate the need to recover legacy or partner IDoc flows safely. Availability does not automatically mean it is the preferred design for new work. On S/4HANA, pair familiar SAP GUI diagnostics with Fiori apps, Universal Journal, ODP, RAP/CDS or released APIs where those are the strategic surface for the process.
Common pitfalls and how to diagnose them
- Reprocessing thousands of IDocs before fixing the root cause. Recheck the exact keys and chronology before changing configuration or reposting data.
- Assuming every error status is safe to rerun without checking duplicate-posting risk. Recheck the exact keys and chronology before changing configuration or reposting data.
- Using BD87 when the IDoc must actually be recreated from corrected source data. Recheck the exact keys and chronology before changing configuration or reposting data.
Whose problem this is
Primary ownership normally sits with the BTP INTEGRATION team. Bring in Basis for infrastructure/runtime issues, Security for authorization evidence, and ABAP or integration developers only when the transaction evidence points to custom logic or mapping. A useful escalation includes exact keys, timestamp, expected result, actual result and checks already completed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd87ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.