ClearBook – Shared Ledger for Buyers & Sellers
A real-time shared digital ledger that lets buyers and sellers track transactions, payments, outstanding balances, and credit history from a single source of truth — replacing spreadsheet and WhatsApp-based reconciliation with instant sync, smart payment reminders, and a referral-driven growth loop.
Tech Stack
Responsibilities
- Designed and built the full-stack shared ledger platform end to end — schema, API, and Next.js frontend
- Modeled the MongoDB schema around a single shared transaction/ledger entity linked to both buyer and seller accounts, instead of duplicated per-party records
- Implemented real-time sync with Socket.io so invoice, payment, and balance updates appear instantly on both sides without a refresh
- Built the mutual verification flow — a logged payment triggers a confirmation request to the counterparty before the balance updates
- Built multi-business account support so a single user can manage ledgers across several firms from one login
- Implemented smart payment reminders and automated nudges for outstanding dues
- Built the referral credit system rewarding users for onboarding new business partners onto the platform
Case Study
Small and medium businesses in India largely track credit and payments the same way they have for decades — a paper diary, a shared Excel sheet that never quite matches, or a thread of WhatsApp messages that becomes unsearchable within weeks. None of these give both sides of a transaction the same view at the same time, which means disputes over 'who paid what' are routine, and monthly reconciliation between a distributor and a retailer can burn days of manual cross-checking.
ClearBook was built to remove the disagreement entirely by giving both parties one ledger instead of two. A buyer and a seller connect once, and from that point every invoice, payment, and balance change is a single record that both accounts read from — not a copy each side maintains independently.
The core of the system is a shared ledger entity in MongoDB linking a buyer and a seller account, with every transaction, payment, and balance recalculation written against that entity rather than against either party individually. A Next.js frontend renders the ledger view identically for both sides — there is no 'buyer mode' or 'seller mode' data model, only a permission layer determining who can post which type of entry. Socket.io pushes every write to both connected clients in real time, so a payment logged by a retailer appears on the distributor's screen instantly, and vice versa.
The single-ledger model was the foundational decision: as long as each side keeps its own record, disagreement is structurally possible. Making the ledger entity itself the shared unit of truth — rather than syncing two separate records after the fact — removes the reconciliation problem at the schema level instead of patching it with better syncing.
Mutual verification was added because a shared ledger only works if both sides trust it. A payment entry doesn't unilaterally update the outstanding balance — it generates a verification request to the counterparty, and the balance only updates once confirmed. This preserves the 'no disputes' premise instead of just moving the dispute earlier in the flow.
Offline-first logging matters because a lot of ClearBook's real usage happens on shop floors and in warehouses with patchy connectivity. Transactions are captured locally the moment they happen and synced to the shared ledger once a connection is available, so a retailer logging a cash payment never loses that record to a dropped signal.
The referral credit system is a product decision as much as a growth one: a ledger with only one party on it isn't a ledger. Rewarding users in ClearBook credit for successfully onboarding their buyer or seller directly targets the platform's actual adoption bottleneck — getting both sides of a relationship onto the same account.
I built ClearBook end to end as a solo project — the MongoDB data model for the shared ledger and multi-business accounts, the Express/Node API for transactions, payments, and verification flows, the Socket.io real-time layer, the smart reminder and notification system, the referral credit mechanism, and the full Next.js frontend across web and mobile-responsive views.
Key Decisions
Single shared ledger over per-party records
Traditional bookkeeping gives each side its own version of the truth, which is exactly what causes disputes. Every transaction, payment, and balance update is written once to a shared ledger entity both parties read from — there is no buyer copy and seller copy to reconcile.
Offline-first entry with deferred sync
Field usage meant transactions often get logged with no signal. Entries are written locally first and synced to the shared ledger once connectivity returns, so a shopkeeper never loses a transaction because of a dropped connection.
Mutual verification before balance updates
A logged payment doesn't silently change the outstanding balance for both sides — the counterparty gets a real-time notification to verify it. This keeps the ledger's 'single source of truth' claim honest instead of trusting one side's entry blindly.
Referral credits as a distribution mechanism
Because a ledger is only useful once both the buyer and the seller are on it, growth depends on invites, not solo signups. A referral credit system rewards users for onboarding their counterparties, which is what actually makes the shared-ledger model work at all.