crm
How to Structure a Trade Ledger for Manual P2P Exchange Bookkeeping
Your P2P exchange did 40 trades this week and you can't reconcile the balances. Here's how to structure a trade ledger that actually holds up.
It's month-end. You're trying to figure out why your USDT balance is off by $340, and the only record you have is a scroll of Telegram messages and a spreadsheet someone half-updated three weeks ago. You can't find the trade that caused it because nothing was logged consistently. This is how P2P exchanges lose money without ever getting hacked or scammed — they just lose track.
If you're running manual P2P currency exchange — trading fiat for crypto, or one currency for another, over Telegram or WhatsApp — your books are only as good as your ledger structure. Most exchanges start with a messy spreadsheet and pay for it later. Here's how to build one that actually reconciles.
What columns does a P2P trade ledger need?
A minimum-viable trade ledger needs 11 columns: trade ID, timestamp, trader/client name, direction (buy or sell), asset given, amount given, asset received, amount received, exchange rate applied, fee/commission, and running balance per asset. Skip any of these and reconciliation becomes guesswork within a week.
The trade ID matters more than people think. Without a unique, sequential ID, you can't reference a specific trade in a dispute, cross-check it against a bank statement, or find it again when a client says "you shorted me last Tuesday." Use a simple format like YYYYMMDD-001 and never reuse or skip numbers, even for cancelled trades — log the cancellation instead of deleting the row.
Why does your ledger need a separate row for fees?
Because blending your commission into the exchange rate hides your actual margin, and hidden margins are the first thing that breaks when you try to do taxes or explain a discrepancy to a business partner. If you take a 1.5% spread on a $2,000 trade, that $30 needs its own column — not just a rate that "happens to be" 1.5% better than market.
This separation also protects you in disputes. If a client claims they were overcharged, you want to show them: here's the market rate at time of trade, here's our fee, here's the total — not a single blended number they have to trust you on. For actual dispute mechanics, see how to resolve a payment dispute between two P2P traders.
How do you track balances across multiple assets and wallets?
Run a separate running-balance column for each asset you hold (USDT, RUB cash, USD cash, BTC, etc.), updated after every single trade — not batched at end of day. Batching is where most manual ledgers fall apart, because by the time you sit down to update ten trades at once, you've forgotten which cash drawer or wallet each one actually touched.
Structure it like this:
One tab per asset/wallet — don't mix your USDT wallet balance and your RUB cash balance in the same column, even if a single trade touches both.
Opening balance at the top of each period (day, week, or month) so you can reconcile against it.
Running total after every row, not just a final sum — this is what lets you pinpoint exactly which trade caused a discrepancy.
Closing balance vs. actual balance check at the end of each session, logged as its own line, so gaps get caught same-day instead of three weeks later.
A "counterparty confirmed" checkbox per trade, so you know which entries are still waiting on the other side to verify.
Should escrow trades be logged differently from direct trades?
Yes — an escrow trade needs a status field (held, released, disputed, refunded) in addition to the standard columns, because the money isn't actually yours to book as revenue until it's released. Logging an escrowed amount as settled income the moment it hits the ledger is a common mistake that makes your books look better than your actual cash position.
If you're not already using structured escrow for higher-value trades, it's worth setting up — both for the trust signal to clients and because it gives you a natural checkpoint to log status changes. We cover the setup in how to set up escrow for a P2P currency trade on Telegram.
Why does a spreadsheet stop working past a certain trade volume?
Once you're doing more than roughly 15-20 trades a day, or running more than one person on the books, a spreadsheet ledger breaks down — not because the columns are wrong, but because nothing forces consistency. One team member logs the rate before fees, another logs it after. One forgets the trade ID. There's no single source of truth for who a trader actually is across 40 different conversations.
This is the exact gap outlined in why exchange businesses running on Telegram outgrow spreadsheets. The underlying issue is that a ledger is a record of transactions, but your Telegram chats are where the actual trade negotiation, rate confirmation, and client identity live — and if those two things aren't connected, you're reconciling from memory.
CRMChat is a Telegram-native CRM that lets you attach a trade record, client profile, and conversation history to the same pipeline, so every ledger entry traces back to the actual chat where the rate was agreed. Instead of a spreadsheet row with a name in it, you get the full context — who confirmed the rate, when, and what was said if a dispute comes up later.
How do you reconcile the ledger at the end of each day?
Sum each asset column and compare it against your actual wallet/cash balance.
Flag any trade missing a counterparty confirmation and chase it before end of day, not end of week.
Cross-check fee totals against your expected margin rate — a mismatch usually means a rate was entered wrong.
Log the reconciliation result as its own ledger line (balanced / discrepancy amount / resolved), so you have an audit trail of when things went wrong and when they got fixed.
Archive confirmed trades into a separate "closed" sheet weekly, so your active ledger stays short enough to scan quickly.
If you're managing this across a support team rather than solo, the coordination problem gets bigger than the ledger itself — see scaling P2P exchange support on Telegram for how to keep multiple people from stepping on each other's trades. CRMChat also automates lead capture when someone asks about your rate and disappears mid-conversation, which is worth knowing about if half your "missing" trades are actually just abandoned inquiries you never logged in the first place — more on that in what happens when someone asks about your rate and vanishes.
None of this requires exotic accounting software. It requires discipline in the columns you keep and a system that ties every row back to a real, verifiable conversation. Get that right and reconciliation stops being a monthly panic and becomes a five-minute daily check.
