IOSOR

IOSOR Kennis

Debetregels versus bezorgstatus op dezelfde ledger

Koppel elke prepaid-eenheidsafschrijving aan DLR of kanaaluitkomst op één wallet-ledger, zodat finance een sent-badge nooit als gratis geld ziet en een gratis fail nooit als stille afschrijving.

Ledger: Een sent-badge is geen gratis lunch. Op prepaid laat elke billable unit een debetregel achter die finance koppelt aan delivered, failed, undelivered, accepted, connected of needs attention — zonder screenshots. Aparte silo's voor geld en bezorging verzinnen gratis sends en stille write-offs.

IOSOR is white-label prepaid: één wallet over messaging, verification, email, voice en JIT-nummers. USD 20 is de pilotvloer; soft review rond USD 1.000/maand maakt mismatches luider. Nauwe buren: boekhouding van SMS-segmenten; DLR-mislukte-retrybeleid onder prepaid. Hier: geld↔outcome op wallet-niveau.

Sent is geen gratis-geldwaarheid

«Geaccepteerd door het netwerk» is een productevent, geen saldocadeau. Settled units tonen bedrag, valuta, kanaal en intent ID. Niet-billable: geen settled debit of wel release/refund. Sent als gratis bij geldbeweging is een leugen; failed als gratis bij settled debit is het omgekeerde.

Happy path: voorafbetaalde reservering vóór de eerste afschrijving. Fail-pad: Als een prepaid-hold mislukt: auto-refund en statuswaarheid. Correlatie daartussen: één regel die na DLR-lag nog leesbaar is.

Eén regel heeft debit- én outcomewelden nodig

Eén joinbare regel per billable intent:

Veld Waarom
Intent / correlation ID Wallet en product koppelen
Debetbedrag + valuta Bewijs dat geld één keer bewoog
Kanaal + unit-type SMS ≠ voice ≠ verify-units
Outcome / DLR-status Delivered, failed, pending, needs attention
Outcome-timestamp Lag zichtbaar; tweede debit geblokkeerd
Idempotency key Retries hergebruiken geld — idempotentie, retries en geld

Aparte money- en DLR-CSV's zonder gedeelde sleutel forceren verzonnen joins. Liever één export met beide.

DLR- en statuslag zonder dubbele charge

Outcomes komen laat. Pending na settle is normaal; een tweede charge voor dezelfde sleutel niet. Settle één keer onder de hold, werk outcome in-place bij — geen parallelle debit bij DLR-flip. Retries onder één sleutel: één geldbeweging, veel statusovergangen. Finale fail: settled debit met failed outcome of release/refund als nooit verschuldigd — nooit nep-Delivered. Lag in timestamps, niet in dubbele rijen.

Kanaaluitkomsten zijn niet uitwisselbaar

Messaging-DLR ≠ email-accept ≠ verify-succes ≠ voice-connect. «Delivered» overal plakken verbergt burn en breekt caps. Outcome-vocabulaire per kanaal; gedeelde geldkolommen. Wallet-export: charged unit + kanaal-native outcome. Maandeinde: Month-end export van de wallet om 02:00.

Koperschecklist voor ledger-eerlijkheid

  1. Kan finance elke settled debit aan een outcome koppelen zonder ops?
  2. Werkt een late DLR dezelfde regel bij in plaats van een tweede debit?
  3. Zijn retries onder één idempotency key money-safe?
  4. Doen fail-paden release of refund wanneer nooit verschuldigd?
  5. Zijn clientstatussen vrij van upstream-merknamen?
  6. Is spend begrensd met prepaid-uitgavenbeheer vóór volumepieken?

Start met IOSOR

Kies één SMS-eenheid. Hold, settle de prepaid-debet, eis daarna de eind-DLR op diezelfde ledgerrij. Exporteer één regel: debetbedrag, DLR-status, stempels. Een debet zonder DLR — of een DLR zonder debet — blijft een incident. Dit is geld versus bon op één rij, geen CRM-hygiëne en geen alerthandover.

IOSOR takeaway

Eén ledgerrij draagt debet en DLR, anders sluit finance de send niet.

Doe: koppel debet aan de eind-DLR op dezelfde rij en houd ongepaarde rijen open.

Niet doen: sent als settled behandelen, of de maand vanuit chat sluiten terwijl rijen geen bon hebben.

Was deze gids nuttig?

Gerelateerde gidsen