BD20 — Manually Process Inbound IDocs by Message Type
BD20 forces SAP to process all inbound IDocs sitting in status 64 (ready to be passed to the application) for a chosen message type, instead of waiting for the periodic background job to pick them up. It runs the same posting logic the scheduled job uses, so it is a manual trigger, not a repair tool for IDocs already in error status.
BD20 is the manual trigger for inbound IDoc processing, selecting all IDocs in status 64 for a given message type and pushing them into the application posting logic immediately. This page covers when to reach for it versus a background job or BD87, what it actually writes, and the recurring confusion between status 64 and error statuses like 51 or 56.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,106 words
Purpose
BD20 selects inbound IDocs that are sitting in status 64, meaning the IDoc has passed syntax and partner profile checks and is queued waiting for the application posting step, and dispatches them into that posting logic for a chosen message type. It effectively runs the same dispatch that the scheduled background job (commonly built around report RBDAPP01) performs on a schedule, but on demand. The structural fact that causes most confusion is that BD20 only ever acts on status 64. It has no effect on IDocs sitting in error statuses such as 51 or 56, and running it against a message type with no status-64 IDocs simply does nothing, which consultants often misread as a bug.
When it is used
BD20 is reached for when inbound IDocs are visibly stuck in status 64 in a queue and the consultant does not want to wait for the next scheduled run of the background job, typically during cutover testing, after a partner profile correction, or when a batch job that normally drives processing has been suspended. It is a queue-flushing tool, not an error-correction tool. When IDocs are already in status 51 or 56, the reflex is BD87 or the general IDoc monitor, not BD20, because those tools let you reprocess after correcting the underlying data or configuration. In an S/4HANA landscape with modern integration built on CPI or API-based scenarios, BD20 is only relevant where the classic IDoc inbound channel is still in play.
How to use it in practice
- Open BD20 and enter the message type whose queue is stuck; narrow by IDoc number range or partner if the queue spans several senders.
- Execute. The system finds all IDocs in status 64 for that selection and calls the inbound function module associated with the message type for each one.
- Review the resulting list: successfully posted IDocs move to status 53, failures move to 51 (application error) or 56 (further processing needed manually).
- For any IDoc still not at 53, open it in WE02 or WE05 to read the status text and application error before touching configuration again.
Key data objects
- EDIDC - control record; STATUS field is updated as each IDoc is dispatched and its outcome recorded.
- EDIDS - status records; a new row is appended for every status transition BD20 causes, with timestamp and message text.
- EDID4 (or EDIDD on older releases) - segment data; read during processing but not altered by BD20 itself.
- Application tables of the target object (for example customer or sales order tables) - updated only if the underlying posting succeeds, exactly as if the document had been entered manually.
How to prove it in the data
In SE16 on EDIDC, filter MESTYP on the message type and STATUS equal to 64 with DIRECT equal to 2 (inbound) to confirm the backlog before running BD20. After execution, rerun the same query: the count in status 64 should have dropped, with a corresponding rise in status 53 (success) or 51/56 (still failing). Cross-check EDIDS for the same IDoc numbers, filtering on a timestamp close to the BD20 run, to see the exact status transition and the short error text if it failed.
ECC vs S/4HANA
BD20 behaves the same on S/4HANA as on ECC; the underlying dispatch logic for inbound IDocs has not changed. There is no dedicated Fiori app that replicates BD20's mass-by-message-type trigger; monitoring and reprocessing on S/4HANA is more commonly done through the IDoc monitoring transactions or apps, with BD20 remaining a SAP GUI fallback for forcing the queue.
Common pitfalls and how to diagnose them
- Wrong status expectation: the most common ticket is a request to run BD20 against IDocs in status 51 or 56, expecting it to retry the error. BD20 does not touch those statuses. Confirm the actual status in EDIDC before running anything; if it is not 64, the fix belongs in BD87 or the error-specific IDoc monitor after the root cause is corrected.
- Selection too broad: entering only the message type without a partner or date filter processes every IDoc in status 64 for that type, including ones from unrelated interfaces sharing the message type. Check partner number and date range in the selection screen before executing on a shared message type.
- Collision with the scheduled job: running BD20 manually while the periodic background job for the same message type is also active can cause duplicate dispatch attempts and lock waits on the IDoc number. Check the job log (SM37) for a currently running instance before firing BD20.
- Partial success misread as failure: a mixed result list where some IDocs move to 53 and others stay in error is normal, not a sign the transaction failed. Read the result list IDoc by IDoc rather than treating the whole run as pass or fail.
- Authorization gaps: if the executing user lacks authorization for the posting function module behind the message type, the IDoc can fail with a generic status 51 that has nothing to do with the data. Check the application error text in EDIDS before assuming a data problem.
Whose problem this is
This sits with the functional or interface (EDI/IDoc) team, since it requires knowing which message type and partner are affected and what a successful posting should look like. Basis gets involved only if the backlog is systemic, for example a stalled tRFC or qRFC queue affecting many message types at once. A good handover states the message type, the IDoc number range, the status before and after, and whether the scheduled background job was still running at the time.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd20ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.