An accounting operating layer for India

This is a field dossier: our internal working notes, edited lightly for public reading. It is not a shipped-product announcement — the decisions here are direction, and the risks section says plainly what could kill them. The primary source for the teardown is Last Accounting Company's own news post from July 2026.

Last Accounting Company (LAC) is YC S26, out of Finland, co-founded by Sami Laakkonen. Dozens of Finnish companies run on it and more than $80M of transaction value has moved through the system. Its founding claim deserves restating because most accounting software gets it backwards: “interfaceability” is a property of the whole system, not a feature. LAC built its own general ledger rather than layering on Procountor or Netvisor, because you cannot control the data model, evidence links, permissions and audit trails at the edge of someone else's system. Source data — banks, invoices, receipts, contracts — enters once, keeps its provenance and history, and stays linked to the accounting entry it produced. Outbound is stable read interfaces plus limited, typed write actions.

One more structural fact: firm and software are one product. An interface to stale or unreviewed books is worthless, so the review happens inside the same system that generates the work.

Five lessons we take from the teardown

We copy the structure, not the content. Five principles survive contact with our own market:

1. L1 — Own the ledger. Never build on Tally or Zoho internals; integrate read-only. The ledger is the product; everything else is a connector.
2. L2 — Make the evidence chain the data model. Every entry links to its source document and its history. An entry you cannot trace to its receipt is a rumour.
3. L3 — Publish the trust boundary from day one. LAC runs three tiers: reads (books, VAT position, statements, invoices); limited writes (document upload, invoice drafts, filing review requests); and portal-only, never API (payroll approval, settings, user access, keys). Stating this publicly is a marketing asset as much as an engineering decision.
4. L4 — Name the agent, name the signer. LAC's agent Björn is messageable from inside any workflow, and humans sign off on filings. Personality makes automation legible; accountability makes it sellable.
5. L5 — Expose an MCP/API surface. Claude, ChatGPT and custom agents operate the books through it, and other tools build on top. Accounting becomes infrastructure, and infrastructure compounds moats beyond price.

Where India bends the model

The operating rhythm maps one-to-one. Finland's VAT and payroll cycles find their counterpart in the GST stack — GSTR-1, 3B and the annual GSTR-9 — plus TDS, e-invoicing with IRN above turnover thresholds, advance tax schedules and MCA filings. Monthly plus annual cadence, rigid deadlines throughout: the LAC operating model transfers intact.

What differs is the ecosystem. Indian SMBs live inside Tally or Zoho Books and their accountants resist replacement — which L1 already told us not to fight on day one. So the entry point narrows:

• Wedge segment: D2C and ecommerce SMBs — Shopify brands, Amazon sellers, Flipkart sellers. Highest transaction volume, the most reconciliation pain, least loyalty to legacy tooling.
• Connector priority: bank first, through the Account Aggregator framework plus direct bank feeds; then Razorpay and Stripe settlements; then marketplace payout reports from Amazon and Flipkart; the email inbox as the purchase-invoice trap; and a Tally XML export path for switchers.

GSTR-2B mismatch: the feature LAC cannot follow us through

The killer feature is regulatory, and therefore defensible: input tax credit (ITC) mismatch detection against suppliers' GSTR-2B filings. Indian businesses lose credit — real money, every month — when a supplier fails to file. It is the single most common cash leak in the GST system, and clearing it today means a human chasing other humans. Automated vendor-chasing turns it into an instant ROI story: “we found ₹X of credit you were about to lose.” Doing it well requires years of accumulated India-specific rule handling, which is exactly the depth a global player entering later cannot shortcut.

MVP architecture

• Ledger core: a double-entry store with append-only entries; every entry carries an evidence_id pointing at its document — PDF or email extract — and an immutable audit log records every touch.
• Ingestion agents: a classifier (document type, entity, GST fields), an extractor, and a reconciler matching transaction ↔ document ↔ ledger entry with confidence scores. Anything under threshold queues for human review instead of guessing.
• Filing engine: GSTR-1 and 3B builders derived from ledger state. Validation rules are versioned code, never prompts — a rule that must hold goes in code.
• Human layer: a chartered accountant's dashboard showing only the exception queue and a monthly sign-off checklist, with digital signature on filing packets. The CA sees exceptions, not data entry.
• Client surface: a WhatsApp or Telegram bot — “where is my ITC this month?” — plus a web dashboard. Zero data entry demanded from the client, ever.

Risks, stated honestly

• R1 — Trust. Accounting firms are sticky and risk-averse. Counter: a free quarterly audit with published accuracy metrics, and a CA signature on every filing from day one.
• R2 — Regulatory liability. We partner with a licensed firm initially rather than hiring chartered accountants in-house immediately. Liability follows licensure.
• R3 — LAC-style players entering India. Counter with speed and GST depth — 2B matching alone requires years of India-specific rule accumulation. The moat is the boring rulebook.

This dossier applies the accounting case derived in three markets, one thesis; the product it informs is scoped — and being built — in the Numera lab note.