Correlation IDs across debit and DLR

When money and delivery live in separate tools, month-end becomes chat archaeology. A correlation ID is the stable join key that ties the prepaid debit row to the DLR (or signed status event) for the same intent. Without it, finance sees spend and product sees status — neither can prove they describe one send.

This page is the join contract, not a Verify-session export playbook and not a full debit-vs-status ledger primer. Related: Debit rows vs delivery status ledger, Verify session correlation for finance export, Shared status language for product and finance, Missing signal is not Delivered, Ops signal board when volume is live.

IOSOR is white-label prepaid. USD 20 funds a join pilot; soft review near USD 1,000/month prices missing joins as recon debt. Clients see white-label outcomes only.

Correlation is not a chat thread

Slack links and ticket titles are not join keys. The ID must be generated at hold/intent creation, carried on the debit row, and echoed on every terminal DLR/status event. Retries reuse the same ID under the same idempotency key. If support pastes a different string each hour, you do not have correlation — you have folklore.

Same id on debit and DLR

Product and finance open the same id for the same UTC window. A delivered DLR without a matching debit — or a settled debit without a terminal status — is an incident, not a soft yellow. See Missing signal is not Delivered.

Finance join without archaeology

Month-end should filter one column, not reconstruct from screenshots. Export: correlation id, debit amount (USD), hold→settle, terminal status, timestamps. Soft USD 1,000/month treats unmatched joins as recon tickets; USD 20 proves the join on a small corridor before volume language. Adjacent Verify story: Verify session correlation for finance export — different debit shape, same join discipline.

Missing join is an incident

Do not auto-map orphan DLR to delivered spend, and do not settle blank-id debits as “probably fine.” Open recon, keep status honest (missing/unknown until joined or named closure), and block “Live volume” language while join health is red on the Ops signal board when volume is live. Shared vocabulary: Shared status language for product and finance.

Buyer checklist for correlation IDs

1. Correlation id minted at hold/intent — not invented in chat?
2. Debit row and DLR/status carry the same id for retries?

Start with IOSOR

Create the correlation ID at hold, write it on the prepaid debit row, and require the same string on the terminal DLR. Export one joined row: hold id, debit amount, DLR status, timestamps. Any debit without a matching DLR — or a DLR without a debit — stays an incident. This is a money-to-receipt join, not a request-path trace.

IOSOR takeaway

Debit and DLR share one ID or finance cannot audit the send.

Do: generate the ID at hold and refuse unmatched joins as incidents.

Don't: invent a new string at webhook time, or reconstruct month-end from chat threads.