BahiALPHA

What's next

• Sidebar has 60+ routes grouped into 10 sections — explore at your own pace. Hit ? any time for the keyboard cheat sheet.
• Backup Now in the topbar (or Ctrl+Shift+B) writes a dated archive zip — do this at the end of every working session and keep one offsite copy.
• Settings → Safety & failure modes — read this once. It explains what's protected against (browser crash, multi-machine, file corruption) and what isn't.

Where your data lives

Your .khata file is a zip archive. Unzip it from the command line and you'll find:

• manifest.json — metadata, schema version, integrity hashes, audit log head
• books.sqlite — the double-entry ledger as a regular SQLite database
• snapshots/ — rolling snapshots of previous saves
• attachments/ — scanned bills
• exports/ — cached report exports

The format is published in khata-format.md. Anyone can write a .khata reader or writer — Bahi is just one implementation.

Daily

The work the accountant does every morning. Raise invoices, record receipts, enter purchase bills, pay vendors.

Weekly

Housekeeping tasks. Review masters, reconcile bank, add new items and series.

Monthly

Period close and statutory filings. Dashboard review, aging, GST returns and TDS returns.

Inventory (goods companies)

Every inventory route in sequence. Pharma has the full story — dashboard, stock on hand, register, valuation, batches, aging, godowns, DCs, e-way bills and transfers.

Accounting & journal

Free-form accounting entries — journal voucher, day book, ledger lookups, registers.

Yearly & governance

Trial balance, financials, period locks and year-end rollover.

How CA mode works

The screenshot tour below shows what review looks like in practice. This subsection covers the layer underneath it — how CA mode behaves, what your CA profile is, how to add a client, and what happens if the owner edits in parallel.

The problem CA mode solves

Without CA mode, the typical handoff is messy: the owner sends a .khata to the CA via email / WhatsApp / Drive, the CA opens it pretending to be the owner, makes adjustments (year-end, depreciation, prepaid, outstanding, accruals), sends it back, and the owner has no visible record of what changed.

With CA mode, Bahi tags every action the CA takes with actor='ca' in the audit log automatically, stamps the CA's name + firm + ICAI membership on each entry, lets the CA mark entries reviewed and attach annotations, generates a formal PDF Review Report with the CA firm letterhead, and — when the owner reopens the file — surfaces exactly what was added, the review report, the annotations, and any to-dos to react to.

One-time setup

Click the OWNER badge in the topbar (or use Ctrl+Shift+M) and confirm the switch. The first time you enter CA mode, Bahi shows the CA profile setup modal:

• Your name
• Firm name
• ICAI membership number
• Logo (optional, ≤200 KB) — appears on review reports

This profile is stored in your browser's IndexedDB, never inside any client .khata file. It's per-machine, so if you work from two laptops you set it up on each. Edit later via Settings → Edit CA profile.

Adding a client

Workspace → + Add client → pick the client's .khata. Bahi validates the format and adds it to your Client list. Each card shows client name + GSTIN, last-reviewed date, unreviewed entries count, and last-opened.

Every time you open a client file, Bahi runs the Layer 3 ancestry check against the previous open's audit log head. Five outcomes:

• Identical — same audit head as last open → silent, proceed
• Fast-forward — incoming file is downstream (owner posted new entries since you last had it) → silent, proceed
• Same GSTIN, no shared ancestry — file shares no history with your last copy → warning toast (probable cause: fresh export, restore from old backup, or different file with the same GSTIN)
• Divergent — both you and the owner have new entries the other doesn't → routes to the Reconciliation View (see below)
• Different GSTIN — hard block; you've opened the wrong file

Annotation types

Click + Note on any review row, or use Sidebar → CA → Annotations. Six types:

• Comment — generic note
• To-do — something you'll come back to
• Flag — needs attention but no specific action
• Reclassified — you posted an adjustment to move an entry; this annotation explains why
• Missing bill — supporting document is missing; ask the client
• Confirm with client — needs the client's input before finalising

Each annotation captures your CA identity (name + firm + ICAI membership) at creation time as a snapshot. If your firm renames itself later, last year's annotations still show last year's firm name — same invariant as invoice, customer, and vendor snapshots.

Adjustment voucher types

Sidebar → CA → + Adjustment voucher (or F7 for a journal voucher). The form is a thin wrapper around the journal-voucher engine with one extra field — Adjustment type:

• Year-end — closing entries that aren't full FY rollover
• Depreciation — fixed-asset depreciation
• Prepaid — prepaid expenses → reclassify as expense
• Outstanding — outstanding expenses → reclassify as liability
• Accrual — revenue / expense accrual
• Other — anything else

Posted via the same postEntry engine as native journal vouchers, but with actor='ca' and a dedicated ca.adjustment audit log action. The owner sees this entry tagged as a CA adjustment with your name, firm, and the adjustment type.

Sending the file back

Two options:

• File system (simplest) — save the file (any save action does this; or hit Ctrl+S), send the .khata via your normal channel, tell the client to open it in Bahi.
• Backup zip with the review report bundled (cleaner handoff) — hit Backup Now (or Ctrl+Shift+B). Bahi writes a dated .khata-backup.zip containing the file + audit log CSV + meta.json. Add the PDF review report to the same zip manually. Send the zip.

Either way, the owner's next file open triggers the Layer 3 ancestry check on their side. Your audit log head is downstream of theirs → fast-forward, proceed silently. They see the new audit log entries clearly attributed to you.

Reconciliation — when the owner edited in parallel

If the owner posted new entries while you were reviewing — the "we both made changes" scenario — Bahi detects it on the owner's next file open. Their workspace's last-known head doesn't match the head of the file you sent back, AND their audit chain has entries you don't have, AND your audit chain has entries they don't have.

Bahi opens the Reconciliation View automatically for them:

• Header banner with the common ancestor hash, both branch heads, and per-side counts of unique entries
• Side-by-side checkbox lists — local branch (owner) on the left, imported branch (you) on the right, default = keep all from both sides
• Pre-merge summary of how many entries will come from each branch

The owner unchecks anything they don't want, then Build merged file. Bahi runs the replay engine — takes the local DB as the base, walks the picked imported entries in chronological order, and re-executes them via the existing posting bridges. The merged manifest carries integrity.parentHashes = [localHead, importedHead] so the file knows its lineage from both branches, and the audit log gets a merge.commit entry. Nothing is silently lost; both branches' work is preserved; the owner is in control of the merge decisions.

What CA mode is, and isn't

It is:

• A way to attribute every action to either the owner or a specific CA via the audit log's actor field
• A way to attach notes to ledger entries that survive handoff
• A way to generate a formal PDF review report with your firm letterhead in one click
• A way to safely round-trip a .khata file between owner and CA without silent overwrites

It is not:

• Real-time collaboration — Bahi is local-first; multi-CA workflows on the same file are not supported (the same problem as multi-machine concurrent editing)
• A way to lock the owner out — they can still post entries in parallel; the Reconciliation View exists to handle that
• A way to delete or hide owner entries — the audit log is append-only; your adjustments are additive
• A multi-firm workspace — each browser stores one CA profile. If you work for two firms with different membership numbers, use a separate browser profile (Chrome / Brave / Arc profile) for each

Client 1 — Pharma (Vaidya Life Sciences)

CA opens pharma.khata. Mode badge turns into the CA tile. Review workflow begins.

Client 2 — Manufacturing (Shree Krishna Steel)

Close client 1, open client 2. Same keystrokes, different client.

Client 3 — Consulting (Arjun Rao Advisory)

Close client 2, open client 3. Services-only balance sheet, and a CA adjustment voucher example.

What gets imported, what doesn't

Step 1 — Export from Tally

Tally Prime

1. Open your company in Tally Prime.
2. Gateway of Tally → Export → All Masters, format XML → save to a known folder.
3. Gateway of Tally → Export → Day Book, format XML, set the date range (or full year) → save to the same folder.

Tally ERP 9

1. Open your company in Tally ERP 9.
2. Gateway of Tally → Display → List of Accounts → Alt+E (Export), pick XML, save.
3. Gateway of Tally → Display → Day Book → Alt+E (Export), pick XML, set the period, save.

Either path produces two XML files. You can combine them into one (most CAs do) or import them sequentially — Bahi handles both.

Step 2 — Run the wizard

In Bahi: Workspace → Import from Tally… → pick your Tally XML. Bahi parses the file (usually under 2 seconds for an SMB year) and routes you to a 6-step wizard.

1. File summary

   Source company name + GSTIN (from the Tally <COMPANY> element), detected format (Prime / ERP 9), counts of groups / ledgers / stock items / godowns / vouchers, the voucher date range, and a voucher-type breakdown with supported / unsupported flags. If unsupported is under ~5% of total you're fine — otherwise look at the breakdown and consider fixing in Tally first.

2. Date range filter

   Defaults to the full file range. The picker has a live count that updates as you change the dates. Common scenarios: first migration (import everything), year-by-year (import current FY first, then the previous), period-end (import only since the last close).

3. Mapping review

   Tally and Bahi both use a chart-of-accounts hierarchy, but Tally has 28 reserved groups plus whatever customs you've created. Bahi auto-maps the reserved groups; your custom groups go into a Needs mapping panel that hard-blocks Continue until every row is resolved. Common picks:

   • Custom expense group ("Marketing", "Office") → Indirect Expenses
   • Custom income group → Sales
   • Custom liability group → Current Liabilities
   • Custom asset group → Current Assets

   Auto-mapped groups sit in a collapsible section above. Click any row to override if Bahi got it wrong.

4. Commit target

   Two options:

   • Create new .khata file — fresh file with the Tally company info pre-populated. Safer; recommended for first-time imports.
   • Merge into currently-open file — adds the Tally data to the file you have open. Customers and vendors are deduped by GSTIN (or name if no GSTIN). Voucher-number collisions get a TALLY- prefix so you can see which records came from import.

   For merge mode, Bahi shows a live preview of how many customers will be matched vs created (and the same for vendors).

5. Dry-run preview

   Final counts before committing: customers, vendors, items, godowns, supported vouchers in range, unsupported vouchers that will be skipped. Verify the date range and the commit target. Click Commit import.

6. Result

   Bahi runs the import in a single SQL transaction (any failure rolls back cleanly) and shows: created / matched counts per category, the auto-cleaned-to-services list (stock items that looked service-shaped — zero opening stock, no HSN code, name contains "service" / "consulting" / "advice" / "fee" — were imported as services with inventory disabled), the cost-centre warning, the multi-currency warning, skipped vouchers with reasons, and the unsupported voucher types with counts.

   Click Download import report to save a JSON file with the full result for your records. Keep it alongside the original Tally export as the audit trail of the migration.

Step 3 — Verify the import

Don't skip this. Migration mistakes are easier to catch on day one than six months later.

1. Trial Balance (Sidebar → Reports → Trial Balance) — verify total debits and credits tie. A mismatch usually means a few vouchers were skipped — cross-check the count against the import report.
2. Customer + vendor totals — pick three of each at random and verify the outstanding balances match what Tally showed.
3. Stock on hand (Sidebar → Inventory → Stock on hand) — for goods items, verify the opening + post-import quantities are right.
4. Sales register for the most recent month — invoice count should match Tally.
5. GSTR-3B summary (Sidebar → Compliance → GSTR-3B) for the current period — total CGST/SGST/IGST should match the Tally summary.

Once you're confident

• Hit Backup Now (Ctrl+Shift+B) to save a dated .khata-backup.zip. Keep one copy offsite.
• Decide your handoff date with Tally — usually the start of a new month or new financial year.
• From that date forward, post directly into Bahi. Don't dual-post into both Tally and Bahi — keeping two systems in sync by hand is the same problem as multi-machine concurrent editing, and it doesn't work.
• After 30 days of clean Bahi posting, retire the Tally license (or keep it read-only for historical reference).

Common gotchas

If something goes wrong

The import is wrapped in a single SQL transaction. If anything fails mid-import, the database rolls back to its pre-import state and a tally.import.failed entry appears in the audit log with the error message.

If the import succeeded but the result looks wrong: open Settings → Snapshots — Bahi captured a snapshot just before the import. Restore it to a fresh .khata file and start over with different mapping decisions. If you used merge-into-existing, restore the snapshot to undo the merge. If you used create-new, just delete the new file and re-create from the original Tally XML.

What the Tally importer is, and isn't

It is:

• A one-way migration tool (Tally → Bahi)
• An orchestrator over Bahi's existing posting engine — imported records are forensically and behaviorally indistinguishable from natively-posted ones

It is not:

• A bidirectional sync tool — going Bahi → Tally is a separate (and much lower-value) feature
• A reader for Tally .tcp backup files (proprietary binary, not handled)
• A reader for encrypted Tally Cloud / TallyVault files (same)
• An IRN / e-invoicing data preserver — Tally Prime exports include IRN data, but Bahi has no IRN field yet