The shift ended; the money did not: a P2P settlement ledger

A trader sees money in an account, the merchant sees funded customer balances and treasury sees an amount due for settlement. These are three different views. In a P2P operation, arguments often start because one party counts gross receipts, another has already deducted withdrawals and a third treats collateral as available cash. Closing the day must connect these views without erasing their differences.

The following management ledger is hypothetical. Every amount and fee is an arithmetic assumption, not a market claim or an actual provider's tariff. The model assumes that the participating entities and accounts are permitted to collect and pay these funds. An accountant must adapt account names and entries to the contract and applicable accounting requirements. This is an aggregate management view across approved accounts, not a proposal to mix customer and own funds in a single bank account.

Opening positions and movements

The processor starts with 20,000 currency units of available operating cash. In this model, 12,000 represents an existing payable to the merchant and 8,000 is the processor's own funding. A security deposit of 5,000 is held separately under restriction. It is outside the operating 20,000 and is not revenue.

During the day, the bank source confirms new receipts of 100,000. Of these, 98,000 can be linked unambiguously to the merchant's customer deposits. Another 2,000 remains unallocated: the money arrived, but there is insufficient evidence to credit a particular player. The ledger retains a separate obligation while that is investigated. An unidentified receipt does not become shift revenue.

Under approved merchant instructions, the processor executes player withdrawals of 60,000 and a refund of 1,000. Assume the contract charges 2% only on confirmed, allocated receipts and a separate aggregate fee of 300 for that day's executed withdrawals. The first fee is 1,960 and total compensation is 2,260. These are solely the terms of the example.

The processor also sends the merchant a separate settlement payment of 40,000. The closing merchant payable is opening 12,000 plus allocated receipts of 98,000, less withdrawals of 60,000, the refund of 1,000, fees of 2,260 and settlement of 40,000. The result is 6,740.

A control total still needs supporting detail

Closing operating cash is 20,000 plus 100,000, less 60,000, 1,000 and 40,000: a total of 19,000. Its components are the merchant payable of 6,740, unallocated receipts of 2,000, original own funds of 8,000 and earned compensation of 2,260. Those components also total 19,000. The restricted 5,000 deposit is reconciled separately.

This equality is useful, but it does not prove every transaction is correct. Two allocation errors can offset each other. The controller therefore checks unique links between each bank movement, processor order, merchant customer transaction and settlement line. A single incoming transfer must not fund two customer deposits merely because their amounts match.

If the bank confirms a completed withdrawal while the processor still shows it pending, a repeat payment becomes possible. If the processor marks it complete without bank confirmation, the obligation to the recipient does not disappear. These cases need separate states rather than a balancing adjustment made to produce an attractive zero.

Where one day ends and the next begins

Suppose another 4,000 arrives after the agreed cut-off, although the order was created earlier. Assigning the amount by order time may suit operational analysis, while the bank ledger puts it in the next period. Explain the difference through event time, booking time and the agreed time zone. Silently changing yesterday's file is dangerous: the merchant may already have treated it as final.

A practical design closes the period with an outstanding-items schedule and publishes later corrections separately. Preserve the previous value, replacement value, supporting reason and approving employee. The trader owns primary evidence, the reconciler owns matching and treasury owns cash availability. Small teams combining roles need independent review of material corrections.

Why collateral does not cure a liquidity gap

Security covers specified contractual risks and may be restricted. Bybit describes frozen P2P advertiser collateral that may compensate counterparties. These are platform-specific terms, not a guarantee for every trading team.

In our example, the merchant payable of 6,740 cannot automatically be treated as covered by the 5,000 deposit. Establish who owns the collateral, who benefits from it, when it may be applied and whether it can actually be accessed. If it cannot fund today's withdrawals, its available value in today's liquidity plan is zero even if it remains an accounting asset.

Currency conversion needs its own line

Consider a separate conversion example, excluded from the preceding daily ledger: the merchant must receive the equivalent of 10,000 units of currency A in currency B. The hypothetical agreed rate is 0.90 B per A, creating a 9,000 B obligation. Treasury actually acquires B at 0.895 and pays a separate fee of 20 B. On these assumptions, it obtains 8,950 B before the fee and has 8,930 B available afterward. The 70 B shortfall must not be hidden among unidentified receipts.

Responsibility depends on the agreed rate-lock and fee mechanism. If the obligation was fixed at 9,000 B, the processor must explain and fund its execution result. If a different mechanism was agreed, the ledger must reflect that mechanism. A digital settlement asset additionally requires asset quantity, network, fees and receipt confirmation; calling an asset a stablecoin does not make it bank currency.

A closed day means that every difference has a place and an owner. It does not necessarily mean no items remain outstanding. A clearly disclosed 2,000 awaiting allocation is much more useful to the next shift than a reconciliation that has only been made to look complete.