Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenKhata gets a business's books into a state a Chartered Accountant can review, and stops there — it has no state for certified, signed off or filed, because those are the CA's own acts.
Khata is a double-entry bookkeeping layer: a chart of accounts, a balanced journal, reconciliation against imported bank statement lines, a document register that gates everything on a human confirmation before it reaches the books, and a handoff pack that freezes a closed period's figures for an accountant to review. Its most important design decision is an absence: the handoff status enum has exactly four members — prepared, sent_to_accountant, changes_requested, withdrawn — and no member means certified, signed off or filed. There is no value to write for the terminal act, so no route, admin or future contributor can accidentally record one. Khata is a regulated agent under this product's own domain model (Domain.ACCOUNTING): under s.26 of the Chartered Accountants Act, only an ICAI member may sign in a professional capacity.
Laxmi, Khata and Dena each model money, and a person will experience the three as overlapping. Khata is the one that gets the books into a state a Chartered Accountant can sign off on — invoices and cash-flow live in Laxmi, and reading a bank account you have not entered into either lives in Dena. They are three separate registers today: a statement imported into two of them lands in two places that never reconcile with each other. There is an open product decision about whether that should change — see docs/REQUIRED_FROM_USER.md §3.6, which an internal 2026-08-16 review turned urgent by finding that Dena masks account numbers in statement narrations and Khata does not, so importing one bank file into both agents, which the product actively invites, can defeat Dena's no-credential-storage guarantee from inside the same product. Until that is resolved: pick Khata for accountant handoff, Laxmi for running the business, Dena for reading a bank account — and do not expect the same statement imported into more than one of them to agree with itself.
It cannot certify, sign off or file your books — the state does not exist to write
Asking to mark a handoff certified, signed_off, filed or finalised is refused with a 403 and a redirect to a qualified accountant, and the refusal itself is audited. This is not a permission check on an enum member that happens to be missing — the words are matched explicitly so the caller is told what the product does and does not do, rather than receiving a validation error about an unrecognised string.
A journal entry cannot be edited or deleted — only corrected by a new one
There is no PATCH or DELETE anywhere on the ledger. The only correction route posts a new entry that points back at the original, generated as an exact reversal from the original's own lines rather than hand-typed, because a hand-keyed reversal is the one correction that could itself be wrong.
A closed period refuses every write
Closing a period freezes it: posting an entry, correcting one, or importing a statement line into a closed period's dates is refused with a 409 naming the reopen route and asking for a stated reason. Reopening is a separate act, not a flag on the close route, because it is the exception an accountant most needs to see.
It will not post an unconfirmed document to the books
A captured document sits in needs_review however good its extracted figures look. Only a person confirming the values match the original moves it to confirmed, and posting refuses anything else with a 409 naming the confirmation route — the same gate an OCR-extracted draft would have to pass through.
It will not guess a category — no matching rule returns nothing, not a default
A category suggestion comes only from a rule the workspace itself wrote. When none matches, the response says so explicitly rather than defaulting to a catch-all category, because a silent default is accepted by a busy owner and quietly becomes the largest line in their accounts.
Every trial balance, ledger listing and handoff carries an 'Unaudited' label
The label travels with the data itself — inside the JSON, not only in a UI badge — so a trial balance pasted into an email or exported still says what it is: a working document for a bookkeeper, not a financial statement.
Getting started
Accounts have a unique code per workspace — the handle a CA will use in a review comment — and a period needs a start and end date before anything can be posted into it. Every period starts open.
A manual entry needs balanced lines in integer minor units. A captured document — a receipt or invoice — sits in needs_review until a person confirms its extracted figures match the original; only then can it be posted, and posting writes exactly one balanced entry pointing back at the document.
Closing freezes the period and captures how many statement lines were still unreconciled at that moment. The handoff pack can only be assembled from a closed period, and it freezes the trial balance and every unflattering fact — unreconciled lines, documents with no retrievable original, entries already corrected once — as it stood on the day.
Capabilities
Balanced double-entry posting and a recomputed trial balance. Money is integer minor units beside a currency column, never a float. Entries are append-only: a correction is a new linked entry, and there is no PATCH or DELETE on the ledger at all.
Every mutating handler writes an entry with actor, action, entity and detail. The only public surface is a GET — no route writes, edits or deletes the log.
A closed period refuses every write, and reopening is a separate route needing a stated reason, counted and audited. A standard task set now generates idempotently per fiscal year from a curated template — the same precedent the default chart of accounts sets — and every entry posted after a period was reopened is surfaced as a post-lock exception, computed fresh from the ledger rather than a table that could itself go stale. Checklist wording states plainly that 'complete' is not audited.
A recorded state carrying a stored trial-balance snapshot and everything outstanding — unreconciled lines, documents with no retrievable original, entries already corrected once — as it stood on the day it was prepared. An invitation is now one row for its whole lifecycle — pending, accepted, revoked, expired — with a one-time bearer token this table never stores in the clear, plus comments and change requests that hit the audit trail like any other action. The invitation exists and can be accepted by link either way; only the email that carries the link needs the credential below.
Needs: ZeptoMail (ZEPTOMAIL_API_KEY, a verified sending address) to deliver the invitation email — the invitation record, comments and change requests work without it
Register, checksum duplicate refusal and lifecycle work locally, and a row reports whether its original is actually retrievable. Presigned upload (reusing Socie's own storage service rather than reimplementing it), bulk registration with per-item duplicate reporting, and a signature-verified inbound-email webhook all run against the workspace's own data with checksum dedup and guarded free text.
Needs: object storage credentials to store an original file, and a KHATA_EMAIL_WEBHOOK_SECRET plus a chosen inbound-parsing provider for email intake — metadata-only capture works without either
A shared document platform extracts invoice headers and line items from supplied text with no credential, validates them against business rules, and releases only bookkeeping fields to Khata after a person approves the run. Vendor-name aliasing now reconciles a spelling variant before a rule or a person's own category history is applied, and a low-confidence queue surfaces a shaky read before anyone flags it. Only a person-confirmed document can be posted to the books.
Needs: an OCR credential (DOCAI_OCR_API_KEY) to read a scanned image — supplied text already works with no credential
An explicit rule still wins first; with none, the suggestion now falls back to how this exact vendor was categorised before, read straight from the audit trail rather than a second learned-weight table — transparent, reviewable, and named as vendor_history rather than a rule. Still returns nothing rather than a guess when history has none either.
A generic CSV parser — the caller names its own column headers, so it handles bank-format variation with no per-bank template — closes the old no-parser gap with no credential. Everything after parsing is unchanged: de-duplication, masking, scored suggestions, and an unmatched remainder that no suggestion ever shrinks.
GSTIN checksum validation, a curated HSN/SAC reference with a description-based rate suggestion, and CGST/SGST-vs-IGST computed from the issuing branch's own state against the invoice's place of supply, in integer basis points throughout. No live GSTN lookup and no ledger auto-posting on issue, both deliberate design choices, not gaps.
Outward-supply totals compiled from the workspace's own issued invoices, stored as a dated snapshot rather than recomputed silently out from under a stored status, and exported as CSV or JSON. A PDF request is refused by name — no renderer on this deployment — rather than approximated. No GSTN/IRP filing API anywhere, by design.
Manual JSON import of portal-downloaded 2A/2B rows, de-duplicated on re-import by a row hash so re-uploading an overlapping period is normal. Matching a local purchase document against an imported line is fuzzy and computed on read — GSTIN, a normalised invoice number, amount, date — and never stored as a suggestion; only a person's follow-up decision on a mismatch becomes a row.
Transporter, vehicle and consignment data saved per invoice, with the central ₹50,000 threshold flagged automatically from the consignment value. Advisory only, and said so in the response: state-specific intra-state thresholds and category exemptions are real and are not modelled — a person still has to check the destination state's own rule before relying on the flag.
Vendor and salary payments grouped by payee and section against a curated threshold table, in integer-only tax arithmetic. Every worksheet is stamped a draft, not a determination — section applicability is fact-specific and CA review is mandatory. Salary is listed but never rate-computed, because Section 192 is slab-based, not a flat percentage this table can express.
Checklist and item tracking run locally, with an item's status meaning presence — a document was attached — never quality; that review still happens on the document itself. Every skipped reminder is reported by item, never silently dropped.
Needs: ZeptoMail (ZEPTOMAIL_API_KEY, a verified sending address) to send a reminder — checklist tracking itself needs no credential
Compiled fresh from the ledger on every call and kept as a real version history — each compile is a new stored row, never an update, the same reasoning the accountant handoff snapshot already follows. Every statement carries the mandated unaudited label; the balance sheet's own 'balanced' flag is asserted per currency, not blended.
Cash-and-bank balances and receivables/payables ageing in 0-30/31-60/61-90/90+ day buckets, computed fresh from the ledger and a payment-record table (one side an invoice, the other a purchase document, never both) that lets a partial payment actually shrink what is outstanding. Nothing is cached forward. Laxmi has its own, separate cash-flow view over Laxmi's own data — this one reads Khata's ledger.
Cadence, a per-customer pause and a wording guard that refuses any stated legal or collections threat all run locally, and every reminder due is a logged row before it ever tries to send. Laxmi has its own separate draft-and-approve reminder flow over Laxmi's own invoices — this one dispatches straight from Khata's own.
Needs: a connected WhatsApp Business number or an SMS gateway — without one, dispatch marks every due reminder failed with a named reason rather than implying one went out
Each branch carries its own GSTIN and state code; journal entries and documents can be tagged to one, defaulting to NULL (the workspace's own undivided books) for anyone not using the feature. The consolidated dashboard reports the workspace total alongside a genuinely branch-scoped trial balance — filtered on the entry's own branch_id, not reconstructed — so one GSTIN's figures cannot bleed into another's.
Closing valuation computed from a recorded movement history in integer minor units throughout — proportional reduction for the moving average rather than a rounded per-unit figure, so it cannot drift over many small movements. A stock item's method is its own explicit, auditable setting, never a silent global default. Costed per currency and never blended: an item with imported stock priced in a second currency returns each currency's value separately, with the reported total naming the one currency it is in — the same per-currency discipline the balance sheet applies.
API surface
Every route below is mounted and reachable today. Requests and responses are real shapes, not illustrations.
Balanced entries in integer minor units, and the only way to fix a posted one.
/api/v1/agents/khata/ledger/journal-entriesPost a balanced entry — every line is checked before anything is written (HTTP 201). That entry moves INR 50,000.00. Debits and credits are two non-negative columns with a CHECK that exactly one is non-zero per line, so a negative credit is not a representable row and every response carries immutable: true.
Request
{
"period_id": "f1a2...",
"entry_date": "2026-08-16",
"currency": "INR",
"source": "manual",
"narration": "Office rent, August",
"lines": [
{
"account_id": "acc-rent",
"debit_minor": 5000000,
"memo": "August rent"
},
{
"account_id": "acc-bank",
"credit_minor": 5000000,
"memo": "August rent"
}
]
}Response
{
"id": "je-1042",
"entry_no": 1042,
"period_id": "f1a2...",
"entry_date": "2026-08-16",
"currency": "INR",
"source": "manual",
"immutable": true,
"lines": [
{
"account_id": "acc-rent",
"debit_minor": 5000000,
"credit_minor": 0
},
{
"account_id": "acc-bank",
"debit_minor": 0,
"credit_minor": 5000000
}
]
}/api/v1/agents/khata/ledger/journal-entries/{entry_id}/correctCorrect a posted entry — a generated reversal, never an edit (HTTP 201). A second attempt to reverse #1042 returns 409 naming the existing reversal — an entry can be cancelled once. Anything still wrong after that needs an adjustment with its own lines, which the caller has to write and therefore has to think about.
Request
{
"period_id": "f1a2...",
"kind": "reversal",
"reason": "Rent posted to the wrong account"
}Response
{
"id": "je-1055",
"entry_no": 1055,
"narration": "Correction of entry #1042: Rent posted to the wrong account",
"corrects_entry_id": "je-1042",
"correction_kind": "reversal",
"immutable": true
}/api/v1/agents/khata/ledger/trial-balanceDebits and credits per account, recomputed on every read (HTTP 200). There is no `totals` object and no `account_id`: an account row is keyed `code`, and `balanced`, `total_debit_minor` and `difference_minor` sit at the top level. The flat totals are present only while the books hold a single currency — with more than one, `total_debit_minor` is null and `by_currency` carries the real figures per currency, because a blended debit total is not recoverable and a missing one is.
Response
{
"accounts": [
{
"code": "5100",
"name": "Rent",
"type": "expense",
"normal_balance": "debit",
"debit_minor": 5000000,
"credit_minor": 0,
"balance_minor": 5000000,
"currency": "INR"
}
],
"by_currency": [
{
"currency": "INR",
"accounts": [
"… the same rows, grouped"
],
"total_debit_minor": 5000000,
"total_credit_minor": 5000000,
"difference_minor": 0,
"balanced": true
}
],
"currencies": [
"INR"
],
"balanced": true,
"currency": "INR",
"total_debit_minor": 5000000,
"total_credit_minor": 5000000,
"difference_minor": 0,
"label": "Unaudited — prepared for CA review",
"period_id": null,
"as_of": "2026-08-16T10:00:00Z"
}A closed period refuses every write, and an unconfirmed document cannot reach the books.
/api/v1/agents/khata/periods/{period_id}/closeFreeze a period — nothing may be posted into it afterwards (HTTP 200). unreconciled_at_close is captured at this exact moment rather than recomputed later, because after the close the underlying statement lines keep moving and a fresh count would answer a different question than 'what was outstanding when these books were shut'.
Request
{
"note": "August books closed for handoff"
}Response
{
"id": "prd-8",
"name": "2026-08",
"status": "closed",
"closed_at": "2026-08-16T10:05:00Z",
"unreconciled_at_close": 3
}/api/v1/agents/khata/documents/{document_id}/postPosting an unconfirmed document is refused, naming the confirmation route (HTTP 409). The OCR path, when connected, writes into this same register and hits this same gate — an unreviewed machine read cannot become an entry by any route.
Request
{
"period_id": "f1a2...",
"debit_account_id": "acc-office-supplies",
"credit_account_id": "acc-bank"
}Response
{
"message": "This document has not been confirmed by a person, so it cannot enter the books.",
"status": "needs_review",
"confirm": "PATCH /api/v1/agents/khata/documents/{document_id}/extraction with confirmed=true."
}/api/v1/agents/khata/documents/{document_id}/category-suggestionA suggested account and why, or nothing when no rule matches (HTTP 200). When no rule matches, suggestion is null rather than a default category — a silent default would be accepted by a busy owner and quietly become the largest line in their accounts.
Response
{
"document_id": "doc-91",
"suggestion": {
"account_id": "acc-office-supplies",
"rule_id": "rule-4",
"matched_on": "vendor_contains: 'Staples'"
},
"rules_considered": 6,
"disclaimer": "A suggested category is a bookkeeping draft. Whether an expense is deductible or eligible for input credit is the CA's judgement."
}Assembled only from a closed period, and refused the one status it will not write.
/api/v1/agents/khata/handoffsAssemble the accountant pack — only from an already-closed period (HTTP 201). Attempting this on an open period returns 409 naming the close route first — books that can still change cannot be reviewed. available_next_states is published so a client never has to discover by trial that 'certified' is not among them.
Request
{
"period_id": "prd-8",
"accountant_name": "R. Subramaniam",
"accountant_email": "ca@example.com"
}Response
{
"id": "ho-3",
"period_id": "prd-8",
"status": "prepared",
"label": "Unaudited — prepared for CA review",
"snapshot": {
"entry_count": 214,
"correction_count": 2,
"unreconciled_statement_lines": 3
},
"available_next_states": [
"sent_to_accountant",
"changes_requested",
"withdrawn"
]
}/api/v1/agents/khata/handoffs/{handoff_id}/statusAttempting to mark a handoff 'certified' — refused, and the refusal is audited (HTTP 403). The four words Khata will accept here are prepared, sent_to_accountant, changes_requested and withdrawn — every other word describing the accountant's own act is matched explicitly and refused, not merely absent from an enum.
Request
{
"status": "certified"
}Response
{
"message": "Khata cannot mark books as 'certified'. It prepares records for a Chartered Accountant to review; certification, sign-off and filing are the accountant's own acts, on their own systems.",
"boundary": "Domain.ACCOUNTING",
"redirect": "A qualified Chartered Accountant."
}Limits and gotchas
Not just an integer minor-unit column: a 4-byte integer runs out at roughly INR 2.14 crore in paise, a plausible turnover for a customer of this product, so the column is BigInteger.
reopen_count and reopen_reason are stored on the period itself and never cleared, so a books-reopened-twice history is visible to anyone reading the period, not just in the audit log.
A unique constraint on (workspace_id, content_sha256) means the same photographed bill cannot be registered twice, even from two different upload attempts.
Only a person's confirmation becomes a match row. The unmatched remainder returned by the reconciliation route is always honest — a suggestion score never shrinks it.
Unlike Dena, which masks long digit runs in a narration before storing it, Khata's import-dedupe hash includes the description and the bank's own reference exactly as received. Importing the same bank file into both agents can therefore produce a different row count in each — see the Laxmi/Khata/Dena note above.
storage_ref is reported empty rather than implying an attachment that object storage was never configured to hold — the handoff pack counts these documents explicitly.
The caller names its own column headers, so any bank's CSV export works with no per-bank template and no credential. Excel and PDF exports still need a manual CSV re-export first, and there is no live Account Aggregator feed pulling transactions automatically — every import is a file someone chose to upload.
What this needs from you
Everything else on this page works with none of these connected.
| Credential | Unlocks |
|---|---|
| Object storage | to hold the original file behind a registered document — without it, a document row reports that its original is not retrievable |
| An OCR credential (DOCAI_OCR_API_KEY) | to read a scanned receipt or invoice image — supplied text already works through the shared document agent |
| ZeptoMail (ZEPTOMAIL_API_KEY, a verified sending address) | to actually send an accountant-invitation email or a document-checklist reminder — the invitation, checklist and reminder records themselves work without it |
| A connected WhatsApp Business number or an SMS gateway | to dispatch a scheduled payment reminder — cadence, pausing and the wording guard all work without one; without a channel, dispatch marks every due reminder failed and names the reason |
Questions
No, and it structurally cannot: the handoff status it can record has exactly four values — prepared, sent_to_accountant, changes_requested, withdrawn — none of which mean certified, signed off or filed. Asking for one of those is refused with a 403 naming a qualified accountant, and the refusal itself is written to the audit trail.
Not by editing it — there is no PATCH or DELETE on the ledger anywhere. You post a correction, which for a reversal is generated automatically from the original entry's own lines and points back at it, so the mistake and its fix both stay visible.
A 409 naming the reopen route. Reopening needs a stated reason, is counted permanently on the period, and is audited — it is a deliberate exception, not a quiet toggle.
No. A document sits in needs_review however good the extraction is, and only a person confirming the values match the original moves it to confirmed — the one status posting will accept.
It says so — suggestion comes back null rather than a default category, because a silent default is accepted by a busy owner and quietly becomes the largest line in their accounts.
No — they are three separate registers today. Khata prepares books for an accountant; Laxmi runs the business day to day; Dena reads a bank account and answers questions about it. A statement imported into more than one of them will not reconcile with itself, which is an open product decision, not an oversight.
Coming soon