Status 53 in IDoc monitoring means successfully processed by the application, and most people stop checking once they see it, because that's exactly the right instinct ninety nine times out of a hundred. The hundredth time is the one that costs you a Friday afternoon, because status 53 only tells you that the inbound function module ran to completion without raising an unhandled exception. It says nothing about whether the function module itself decided, internally, that something was wrong and just wrote an application log entry instead of failing loudly.
This bit me on an EIM integration carrying maintenance status updates between SIAEC and S/4. The IDoc type wasn't custom, the process code wasn't custom, but the inbound function module had a branch where, if a referenced object didn't exist in the target system yet, instead of raising the kind of error that sets status 51, it logged a warning to the application log and returned a success code anyway, on the assumption that a follow up sync would eventually create the missing object and a later IDoc would pick up the relationship correctly. That assumption was true often enough that nobody noticed for months. It stopped being true for a batch of records where the follow up sync had its own delay, and a chunk of status updates simply never landed, all showing green in WE02.
The application log is the only place that tells the truth
WE02 and BD87 show you the IDoc's own status, which reflects what the processing function module reported back, not necessarily what actually happened to the business data. If that function module is written defensively to avoid hard failures, which a lot of standard and custom inbound logic is, by design, to avoid clogging error queues with things that'll self resolve, you have to go look at the application log, transaction SLG1, or whatever the function module is actually writing to, to see whether a successful IDoc quietly skipped part of its job.
The diagnostic habit that actually catches this: when reconciling a gap between source and target systems, don't start from which IDocs have status 51 or 68. Start from which records exist on one side and not the other, and then trace those specific records back to their IDocs regardless of status. If you find a status 53 IDoc sitting on top of a record that never actually got created, you've found a function module that's optimistic about its own success criteria, and that's a much harder bug to catch through normal monitoring because the monitoring is reporting exactly what it was told to report.
Partner profile retry settings don't help you here either
WE20 retry and reprocessing settings are built around IDocs that fail with an error status. A status 53 IDoc isn't eligible for any kind of automatic reprocessing, because as far as the framework is concerned, there's nothing to reprocess. It worked. If the actual gap only shows up in a downstream report three weeks later, you're not looking at a retry, you're looking at a manual investigation into exactly when the assumption baked into that function module's logic stopped holding, and a manual reprocessing of whatever didn't make it across.
None of this means status 53 is untrustworthy in general, it overwhelmingly is reliable. It means that for any integration where a missing downstream effect would be expensive or hard to detect, it's worth knowing, specifically, whether the inbound logic ever swallows its own errors instead of surfacing them, and treating that piece of the integration as a known soft spot rather than assuming green status means the job is actually done.