The questions we get asked in the security review.

Entity is an agentic AI platform for finance operations, built for Indian finance teams and the firms that serve them. It ships as two products on one platform: Entity Accounting, which does the preparation work — reconciliation, journal entries, receivables, payables and close — and Entity Intelligence, which answers questions and produces reporting, consolidation, variance analysis and MIS off the same ledger. Both run on the ERP a company already keeps rather than replacing it.

No. Entity runs on top of the ledger you already keep, whether that is Tally, Busy, Marg, Zoho Books, or SAP, Oracle, NetSuite, QuickBooks and Xero where a group has moved on. Your chart of accounts, your voucher types and your history stay exactly as they are, and entries Entity prepares are posted into that same ledger. There is no migration and no parallel set of books.

Two kinds of team. In-house finance functions — a controller, a manager and a few preparers carrying a monthly close that arrives before the last one is finished. And accounting, CA and outsourcing firms running the same workflows across many client companies, where the constraint is how many sets of books one preparer can hold. Entity is scoped per company and per role, so a firm can run several clients without staff seeing books they do not work on.

The careful, repetitive, non-judgemental part of the month. Matching a purchase register against GSTR-2B, reconciling a bank statement, reading a vendor invoice and preparing the voucher, chasing the missing document, applying receipts against invoices, and assembling the reporting pack afterwards. Entity claims an 80 percent reduction in manual work and 30 or more hours saved per preparer per month; the judgement calls still come to a person.

Rule-based automation inside an ERP handles the cases somebody anticipated and hands you the rest as an exception list. Entity is agentic: it reads the underlying document, reasons about which ledger and which tax head the entry belongs to, and shows you the evidence for that decision. The practical difference is the size of the exception pile at the end — and that every item in it arrives with the working already done rather than as a line to investigate from scratch.

No. Your ledger, documents and working papers are used to do the work you asked for and for nothing else. Entity does not train models on customer data, and one customer's books are never used to improve anything another customer sees. Where a run needs a third-party model, it goes through commercial endpoints under agreements that exclude the content from training.

Several, routed per task rather than one model doing everything. Model choice is a configuration decision inside the platform, matched to what a step needs on accuracy, latency and cost — reading a scanned invoice, naming a ledger from a messy chart of accounts and drafting a variance explanation are genuinely different problems. Routing is ours to change as models improve, and it changes without touching the workflows built on top.

No, and deliberately not. Entity runs purpose-built agents — a reconciliation agent, a posting agent, a reporting agent — each with its own narrow set of tools and its own scope. Narrow agents can be tested against known cases; one model holding every tool cannot be, and will eventually reach for the wrong one. An agent that has no business posting a voucher is not given the ability to.

Two things. The arithmetic is not done by a model at all — amounts, dates, invoice numbers and tax heads are matched by deterministic code, so the sums are code output rather than generated text. And every answer is returned with the rows and the source document behind it, so a reviewer checks the working instead of trusting the figure. Where an agent cannot ground a number in a source, it says so rather than estimating.

That depends on which deployment you choose, and all three keep the answer in your control. On-premise, the connector runs on a machine on your own network and the ledger, invoices, statements and working papers never leave it. In your own cloud, everything sits in the account and region you already own and audit. In Entity's cloud, each company's books sit in their own isolated store. Data is encrypted in transit and at rest in every case.

It is treated as a real risk, because purchase invoices and emails arrive from outside and are exactly the vector. Content extracted from a document is data to be reconciled, never an instruction an agent may act on, and the harness enforces that by scoping which tools an agent holds rather than by asking a model to ignore instructions. The write path is the backstop: nothing reaches your ledger without a named person approving it.

Both, split on purpose. The match itself is code: amounts, dates, invoice numbers and tax heads are matched by rules that return the same answer on every run, and the rule that produced a match is shown beside it. The model is used only where judgement is genuinely needed — choosing the right ledger out of a messy chart of accounts, or explaining why a break exists — and never to do the arithmetic. Re-running a reconciliation gives you the same result, which is what makes it checkable.

They are surfaced as exceptions with the working already attached — what Entity looked at, what it tried, and why it could not resolve the item. Exceptions are routed to whoever can actually clear them, in the inbox or the chat your team already uses, rather than sitting in a queue nobody opens. The reviewer clears, reassigns or overrules, and that decision is recorded against the item.

At any point, and that is the normal case rather than the failure case. A run is checkpointed at every step rather than being one opaque call, so you can see where it has reached, stop it, read what it did and why, correct it and resume from that point instead of starting again. Nothing an agent prepared is protected from being changed by a person.

Every figure traces back to the voucher it came from, and every judgement carries the rows behind it. You can drill from a consolidated line to the entity, the account, the voucher and the source document in the same view. When we roll a workflow out we also run it beside your existing process first and compare the output against your own close, so the first month is a comparison rather than an act of faith.

On the accounting side: bank and control account reconciliation, vendor statement matching, journal entries drafted from source documents including accruals, prepaids and provisions, receivables with cash application and collections follow-up, payables, books cleanup and close. On the intelligence side: P&L, balance sheet and MIS on any day of the month, plain-language questions answered off the ledger, multi-entity consolidation, budget versus actuals, variance decomposed to the entries that caused it, and anomaly detection.

No, and a rollout that required it would not survive. We map the workflow first — who prepares, who reviews, who signs, and which registers live in the ERP versus a spreadsheet on somebody's desktop — and scope agents to that. Your team carries on filing and forwarding documents exactly as it does today; there is no template to fill in and no new format to learn.

Two-way connectors to the systems Indian finance teams actually run — Tally, Busy, Marg, Vyapar and Zoho Books — and to SAP, Oracle, NetSuite, QuickBooks, Xero, Sage and Odoo where a group has moved on. These are live connectors rather than a one-off import, so the mirror stays current and entries can be written back.

From wherever they already arrive. Invoices are read out of Gmail and Outlook, bank statements are taken as the bank issues them, working papers stay in the Excel and Google Sheets files you keep, and approvals happen in Slack, Teams or WhatsApp where your team already is. Entity reads your ERP's own export format, purchase invoices as PDFs and e-invoice JSON, so nobody has to upload the same document a second time.

Yes, with no reduction in what it does. The connector runs on a machine on your own network and talks to the ERP locally, so for firms whose data is not allowed to leave the premises, none of it does — the ledger, the invoices, the bank statements and the working papers all stay inside your network. The on-premise deployment has the same feature set as the hosted one.

Three. On-premise, where the connector runs inside your office. In your own cloud account and region, so it inherits the network rules, key management and logging your security team has already signed off. Or in Entity's cloud, hosted and operated by us, with each company's books in their own isolated store. Most firms start in our cloud and move on-premise later if their policy asks for it, which does not mean starting the implementation again.

Not without a person. Entries are drafted, reviewed, and only then posted into your ledger as vouchers under the approver's name. The write path is the same one your team would use by hand, so an entry Entity posted is corrected exactly like any other voucher, by anyone who could correct it before.

The first engagement is not a demo — we sit with the people doing the work, read your books and registers, and agree the one workflow worth starting with, typically inside the first week. That workflow then goes live and runs beside your existing process so the output can be compared against your own close. The next workflow is only switched on once the first one holds, so the timeline depends on how many you want rather than on a fixed implementation period.

None yet, and we would rather say so here than in your security review. Entity does not currently hold SOC 2, ISO 27001 or a DPDP audit certificate. The controls those standards test are in place — role-based access, SAML single sign-on, encryption in transit and at rest, a full audit trail, and an on-premise option where data cannot leave your network — but a control is not a certificate, and we will claim one only when we have been independently examined and can hand you the report.

Access is scoped per company and per role, so someone preparing one client's books cannot read another's ledger. The roles map to how a firm is actually staffed — preparer, reviewer, partner — rather than a generic admin-or-user split, and there are no shared logins. This is what makes Entity usable by a firm serving many clients out of one workspace.

Yes, over SAML, so joiners and leavers are handled wherever you already handle them. Taking someone out of your identity provider takes their access to Entity with it, the same day, without anyone having to remember to revoke it separately. That removes the most common access-control failure in a finance team, which is the person who left three months ago still having a login.

Yes, and this is the part the product is built around. Every agent step, every tool call, every source document, and the reasoning behind a match or a mismatch is written to an audit log. The rule we hold ourselves to internally is blunt: if it was not logged, it did not happen. An auditor or a reviewer can reconstruct a run months later rather than being asked to trust a summary of it.

Traffic is encrypted in transit with TLS and stored data is encrypted at rest. Where that is still not enough for your policy — and for a lot of Indian firms it is not — the on-premise deployment keeps the ledger, the documents and the working papers inside your own network entirely, with the same feature set as the hosted option.

Your books were never only in Entity. The ledger stays in your own ERP throughout, entries Entity prepared were posted as ordinary vouchers under a named approver, and the working papers stay in the files you already keep. Stopping means the agents stop; it does not mean unwinding a migration or extracting your history from somebody else's system.

Pricing is not published, because it is set against the workflows you actually put live and the volume behind them rather than a seat count — a firm running reconciliation across forty client companies and a single company closing its own books are not the same purchase. We will give you a number on the first call, once we know which workflow you want to start with. There is no charge for the discovery session.

That is how every engagement starts. One workflow goes live, runs beside how you do it today, and the output is compared against your own close before anything else is switched on. A rollout that cannot be checked against your own numbers is one nobody will trust by month three, so the comparison is the point rather than a concession.

Access to the ledger, the documents as they already arrive, and a few hours with the people who actually do the work. The first session is not a demo — it is going through where the month gets stuck, what takes longest, what gets redone and what nobody wants to own. What comes back is the one workflow worth starting with and a plain answer on what can be automated and what genuinely cannot.

We do. Entity is not a tool handed over with documentation — we map the workflow, build the agents around it, run the first workflow beside your existing process and stay on it through the comparison. That is deliberate: an agent that does not match how a team actually works gets switched off in week three, and the only way to avoid that is to have watched the team work.

Yes, both as customers running Entity across their own client base and through the partner programme. Firms are the case Entity is scoped for — access is per company and per role, so a practice can run many clients in one workspace without staff seeing books they do not work on. There is also an ambassador track for individuals who want to introduce us rather than deliver alongside us.

Email Anmol at a@runentity.com or Kaustubh at k@runentity.com — one of the two founders takes every first call, and the numbers are in the footer of every page. Bring the workflow that annoys you most. If we cannot help with it we will say so on the call rather than after a procurement cycle.