Reaching the khata behind a Khatabook merchant account

Every entry a shopkeeper types into Khatabook is a small double-entry record: who owes, who paid, the amount, the party, and a running balance per customer. The app keeps that ledger in the cloud, syncs it across devices in real time, and lets entries be recorded offline and pushed up when the phone reconnects. That cloud copy — not the screen — is what an integrator wants to reach, and it is the merchant's own data, which makes the consent question clean from the start.

The bottom line: most of what makes Khatabook valuable to a third party — receivables, payment history, invoices, stock — lives in the merchant's own ledger, reachable with that merchant's consent. The lending side is different and sits on regulated rails. We map the two separately and build against whichever the project actually needs.

What a merchant account actually stores

These are the surfaces the app exposes to its own users, named the way Khatabook names them where it helps. Each maps to a discrete record set behind the account.

Three authorized ways in

Khatabook is a financial app holding the merchant's own books, so the route choices are concrete rather than theoretical.

1 · User-consented access to the merchant's account

The merchant owns the ledger and authorizes us to integrate against it. This is the cleanest basis for the customer/supplier records, transactions, invoices and inventory — consent comes from the data owner, so scope and revocation are straightforward. Reachable: everything in the merchant's own books. Durability: high, because it does not depend on a hidden interface staying still. We arrange the consented access with the client during onboarding.

2 · Protocol analysis of the cloud-sync traffic

To get a live, queryable, per-record copy rather than a flat report, we map the app's session and sync calls under the customer's authorization — the OTP/token handshake, then the endpoints that hydrate and update each khata. Effort is moderate and the work is documented as a replayable trace. Durability depends on the app's release cadence, which we account for in maintenance (see below). This is the route that yields a real API surface.

3 · Native export for backfill

Khatabook lets a merchant download transaction data date-wise and generate PDF and Excel reports. That covers a one-time historical backfill without touching any interface, and it is the fastest thing to stand up. It does not give you live sync, so it pairs with one of the routes above rather than replacing them.

What we would actually build: for a live, queryable ledger we map the sync traffic under the merchant's authorization, and we seed the historical backfill from the app's own PDF/Excel export on day one so nothing is missing while the live feed warms up. When a project also needs the merchant's linked bank-statement data, that piece rides the Account Aggregator rails and never touches the app at all.

Reading the sync: a session, then a ledger pull

Indian consumer finance apps in this class authenticate by phone number and a one-time code, then carry a bearer token. The sketch below is illustrative; exact paths, headers and field names are confirmed against live responses during the build.

# 1) Establish a session (phone + OTP -> bearer token)
POST /auth/verify-otp
  { "mobile": "+91XXXXXXXXXX", "otp": "######", "device_id": "..." }
-> 200 { "access_token": "ey...", "refresh_token": "...", "business_id": "..." }

# 2) List the merchant's khatas (customer/supplier ledgers)
GET /v1/businesses/{business_id}/ledgers?sync_since=1718900000
  Authorization: Bearer ey...
-> 200 {
     "ledgers": [
       { "ledger_id": "...", "party_name": "Sharma Stores",
         "type": "customer", "balance": -4200.00, "currency": "INR",
         "updated_at": 1718901234 }
     ],
     "sync_cursor": "1718901234"
   }

# 3) Pull entries for one khata, incrementally
GET /v1/ledgers/{ledger_id}/entries?after=1718901234
-> 200 {
     "entries": [
       { "entry_id": "...", "amount": 1500.00, "direction": "credit",
         "note": "udhaar", "ts": 1718901500, "running_balance": -2700.00 }
     ]
   }

# Pagination + de-dup: page on sync_cursor, key on entry_id,
# reconcile running_balance to catch offline edits re-synced late.

The package you receive

Each deliverable is tied to the surfaces above, not a generic checklist.

• OpenAPI/Swagger spec for the ledger, entries, invoice and inventory endpoints we map, with request/response schemas.
• Auth-flow and protocol report documenting the phone/OTP handshake, bearer-token lifecycle and refresh, and the sync-cursor model.
• Runnable source in Python or Node.js for the key calls — session, ledger list, entry pull, export parsing — with the de-dup logic wired in.
• Automated tests covering pagination, offline re-sync, and multi-script notes and party names.
• Normalized schema that flattens khatas, entries, collections and invoices into one transaction model your systems can consume.
• Interface docs and a data-retention note describing what is fetched, how consent is recorded, and how to honour a withdrawal.

Consent, and where the Account Aggregator rails fit

Two regimes apply, and they apply to different data. The merchant's own bookkeeping is personal data processed under India's Digital Personal Data Protection Act, 2023 — consent has to be free, specific, informed and withdrawable, and withdrawal must be as easy as granting it (the DPDP Rules were notified in 2025). We record consent scope per merchant, log access, minimise what we fetch to the fields a project needs, and work under an NDA where the engagement calls for one.

The bank-statement data that Khatabook's lending flow touches is different: it moves on the RBI Account Aggregator framework, where a licensed NBFC-AA passes financial-account data from the holder to a user with explicit consent and cannot itself read or store it. A government press note put the ecosystem at roughly 2.2 billion accounts enabled and about 112 million users linked. Where a project needs that linked bank data, we integrate through the AA rails rather than scraping it from the app — the lawful path is already built.

What we plan around before writing code

The judgment calls specific to this app:

• Offline-first means late and edited entries. The app captures transactions without a connection and syncs on reconnect, so the same record can arrive twice or change after it first appeared. We design the pull around a sync cursor and per-entry timestamps, de-duplicate on the server id, and reconcile running balances so a re-synced edit doesn't double-count.
• Two data sources, two regimes. The merchant's ledger and the loan-application bank data look adjacent in the product but are governed differently. We scope them as separate sources so DPDP consent covers the ledger and the AA consent artefact covers the bank statements, and neither leaks into the other's retention rules.
• Multi-language content. Party names and entry notes come in English, Hindi and 10-plus regional scripts. We keep the original script, normalise to UTF-8, and test reminders and names so nothing mangles on the way into your store.
• Frequent releases. The app updates often. We keep a small set of captured responses as a replay set and re-check the field mappings each release, so a front-end change surfaces in our checks before it reaches anything you depend on.

Where integrators put this data to work

• Cash-flow underwriting. A lender pulls a merchant's consented transaction history to read real receivables and repayment behaviour, instead of relying on a self-declared turnover.
• Books reconciliation. A chartered accountant or ERP mirrors Khatabook entries into Tally, Zoho or a custom GL so the shop's daily khata and the formal books stay in step.
• Receivables dashboard. A B2B platform aggregates outstanding balances and reminder activity across many merchants to spot who is falling behind on collections.

Screens we mapped

Captured from the public store listing while scoping the surfaces above.

Other khata and vyapar apps in the same orbit

The same integration pattern carries across India's ledger and SMB-accounting category. Named neutrally, for context and a sense of where a unified data layer would reach:

• OkCredit — a digital credit ledger with collection reminders and account statements, the closest functional sibling.
• Vyapar — GST-compatible invoicing and accounting holding bills, parties and stock for micro and small businesses.
• myBillBook — billing and inventory software with GST invoices and party-wise outstanding balances.
• CashBook — a cash in/out and khata tracker focused on daily transaction logging.
• TallyPrime — established desktop accounting with deep GL, inventory and statutory data many shops eventually graduate to.
• Zoho Books — cloud accounting with invoices, banking and a full API-driven record set.
• Busy Accounting Software — GST and inventory accounting widely used by Indian distributors and retailers.
• Udhaar Book — a credit-ledger and bookkeeping app in the same udhaar/khata mould for small traders.

How this brief was built

Scoped on 2026-06-23 from the app's own store listing and feature pages, the published RBI/government material on the Account Aggregator framework, and India's data-protection rules, cross-checked against reporting on Khatabook's move into lending. Primary sources:

• Khatabook — app features and data export
• Dept. of Financial Services — Account Aggregator framework
• PIB — four years of the Account Aggregator ecosystem
• PIB — Digital Personal Data Protection Rules, 2025

OpenBanking Studio · integration desk mapping, 2026-06-23.

Questions integrators ask about Khatabook

Can you separate a merchant's own ledger from the bank data behind a Khatabook loan?

Yes, and we treat them as two sources. The customer and supplier ledger is the merchant's own data held in Khatabook, reached with the merchant's consent. The bank-statement data a lender sees during a loan application travels on the RBI Account Aggregator rails, not from the app's store. We scope and document each one separately so the consent and retention rules land on the right regime.

Does the Account Aggregator framework cover the customer ledger inside Khatabook?

No. The Account Aggregator framework moves regulated financial-account data between licensed institutions with the user's consent. The hisab-kitab a merchant types into Khatabook is the merchant's own bookkeeping, not bank-held account data, so it is reached through user-consented access to that merchant's account rather than through an AA. We use the AA rails only where a project also needs the merchant's linked bank-statement data.

How do you handle entries that were recorded offline and synced to the cloud later?

Khatabook records transactions offline and pushes them to the cloud when the device reconnects, so the same entry can arrive late or be edited after the fact. We pull against the sync cursor and the per-entry updated timestamp, then de-duplicate on the server-side id, which keeps a backfilled or re-synced entry from being counted twice.

What fields come back in a single Khatabook transaction record?

A ledger entry carries the amount, the direction (debit or credit), the linked customer or supplier, a timestamp, an optional note, and the running balance for that party. Invoices add GST and line-item detail; inventory entries add the item, quantity and stock level. Exact field names are confirmed against live responses during the build before any code ships to you.

Working with us

Source for the ledger, entries, invoice and inventory endpoints — the OpenAPI spec, runnable code and tests — runs from $300, and you pay only after it is delivered and you have seen it work. Prefer not to host anything? The same endpoints run as a metered hosted API, billed per call, with nothing upfront. Either way a build is a one-to-two-week cycle. Tell us the app name and the data you want from Khatabook at /contact.html and we will scope it.