SM13 — Update Requests Monitor
SM13 shows the queue of asynchronous database update requests generated by SAP's update task mechanism. It is used when a user reports a document as saved that never actually posted downstream, letting a consultant see whether the update terminated with an error, inspect the failing function module, and reprocess or delete the request once the root cause is understood.
SM13 is the monitoring transaction for the classic SAP update task, the asynchronous mechanism that commits database changes after a dialog transaction reports success. The page covers why a saved document can still be missing downstream, how to read and reprocess an erroneous update request, and why deleting a failed request without functional sign-off creates permanent data inconsistency.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,073 words
Purpose
SM13 displays update requests queued by the SAP update task, the asynchronous layer that decouples the dialog work process from the actual database commit. When a program issues a function module call in update task, the dialog step returns control to the user immediately with a save confirmation, while the real database changes are executed later by a separate update work process. The structural fact behind most confusion with this transaction: the user's green save message only confirms that the request was queued, not that it succeeded. If the update work process later fails, terminates, or is deactivated, the document the user believes is saved may never actually reach the database, and SM13 is the only place that queue is visible.
When it is used
Reached for whenever a business user insists a document was saved but it does not appear in the follow-on process: a goods movement with no accounting document, a sales order with no delivery, a billing document that never generated. It sits between the functional transaction (which only shows the save confirmation) and the technical trace (ST22 for the resulting dump). It is not used to check locks, that is SM12, and not used to check whether the work process itself is alive, that is SM50 or SM51. SM13 is reached specifically when the symptom is a discrepancy between what was reportedly saved and what exists in the database.
How to use it in practice
- Open SM13 and set the selection screen: client, user (or leave blank for all), and a date/time window that brackets when the user says the save happened.
- Set the status filter to show errors first (executed with errors, or not yet executed), rather than pulling the full history.
- Execute and review the list; each line is one update request with its status, program, and timestamp.
- Double-click a request to see the sequence of function modules called and which one failed.
- If terminated, cross-check ST22 for a dump with the same user and timestamp to get the actual error.
- Only after the root cause is understood, either reprocess the request (V1 execute) or delete it, and only after confirming with the functional owner what deletion means for that document.
Key data objects
- VBHDR - update request header: request key, user, program, transaction, status (executed, error, not yet processed).
- VBMOD - list of function modules registered for a given update request, in call sequence, each with its own completion status.
- VBDATA - the actual parameter data passed to each queued function module, stored in cluster form.
- VBERROR - error information recorded against a request when a module in the chain terminates.
How to prove it in the data
In SE16 or SE16N, pull VBHDR filtered on the user and the approximate save time, sorted by status; a status of error or not-processed confirms the update never completed. Take the request key from that row and look it up in VBMOD to see which function module in the chain is marked as failed versus completed. If a dump is suspected, correlate the same user and timestamp against ST22 rather than trusting VBERROR text alone, since the dump has the full call stack.
ECC vs S/4HANA
The classic update task and SM13 remain in use on S/4HANA largely unchanged; the underlying asynchronous update mechanism was not replaced. There is no dedicated Fiori app that supersedes this monitor, since it is a technical Basis-level tool rather than a business-facing one. Consultants working on S/4HANA still use SM13 the same way they would on ECC when chasing a missing update.
Common pitfalls and how to diagnose them
- Terminated update (status error): the update work process hit a dump mid-chain, usually a lock wait timeout, a program error, or a missing master data record. Check ST22 for the matching dump before touching anything in SM13. Reprocessing without fixing the root cause just reproduces the same error.
- Nothing shown for a real complaint: the selection screen filtered it out, most often the date/time window is too narrow or the wrong client was entered. Widen the range and drop the status filter to 'all' before concluding there is no queued request.
- V2 update backlog: statistics and non-critical secondary updates (V2) accumulate when update work processes are undersized or one is stuck. This shows as a growing queue with normal-looking V1 status but a stack of pending V2 entries; check SM50 or SM51 for update work process availability rather than treating it as an application error.
- Deleting a failed request without functional sign-off: this is the reflex fix that causes lasting damage. Deleting an erroneous update removes it from the queue but does not undo whatever the preceding dialog step already committed synchronously, so the document can end up half-posted with no way to reconcile it later. Always get functional confirmation on what the deleted update was supposed to write before removing it.
- Same function module failing repeatedly across different users: this points to a program defect or a systemic master data gap, not a one-off user error. Escalate to ABAP development with the update request key and the associated dump rather than clearing requests one by one.
Whose problem this is
Primarily Basis territory for reading the queue and correlating with work process health. Root-cause fixes for a repeatedly failing function module belong to ABAP development. A good handover includes the update request key, the failing module, the linked ST22 dump ID, and explicit functional confirmation on whether the request can be deleted or must be reprocessed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/sm13ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.