Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-value-date

You may also have suspense accounts for certain types of use cases: https://gocardless.com/en-us/guides/posts/what-is-a-suspense...

We model a timestamp which functionally is "when does this activity go on the books"? We compute clearing both based on this "effective_at" and a "system time" (there are some business functions with known periodicity and it makes for a useful debugging tool).

Long-clearing activity makes for some interesting business cases and long-standing float obviously can lead to some detection noise. For example, Brazil has uniquely long settlement times.

I work with payments in a bank in Brazil and as I was reading the question I thought "interesting question, here we have a great 'delay' in clearances and very old and very complex government-embedded systems to deal with it, funny to see that you know about it too.

btw, are you familiar with Pix? https://www.bcb.gov.br/en/financialstability/pix_en

Well at least some people there should be familiar with it - https://docs.stripe.com/payments/pix

Not the author, but know a little bit about this. You’re describing a payable or receivable, depending on the direction of the funds flow you’re thinking about. You’d have an account for the payable/receivable that should clear. If it doesn’t do that by the expected settlement date, someone or something needs to go look and find out why. The settlement date itself should be predictable based on properties of the submitted transaction and the network/scheme reporting.

The general way you'd handle this is with undeposited or in-transit ledgers. Funds would go Account A > Undeposited Account B > Deposited Account B, where they're typically in Undeposited Account B for N days. All ledgers would balance.

Second. That's exactly how we handle all money flow state transitions in our ledgers.

Using Hedera hashgraph would be interesting