EkCell reads your bank statements and invoices, reconciles them automatically, and cites the exact page and line behind every figure it produces, so no one has to take its word for it.
EkCell did not start as a product. It started as one person's job. In a small team, someone ends up owning the accounting on top of their actual role. Every month end, that person pulled together invoices and bank statements, categorized each line, and prepared the tax and sales invoice paperwork before any of it went to the accountant.
The first version of that work was a spreadsheet. It held up for one company. It did not hold up once a second company joined, or once the person who built it went on leave.
Automation was the easy part to promise. Trust was the one we had to design for, because our accountant was not going to sign off on anything that couldn't be checked firsthand.
Each analyst does one part of the close, and none of them post a number without showing its source first.
Reads bank statements from 50+ banks (PDF or CSV, scanned or native) into clean columns: date, particulars, cheque number, debit, credit, balance. Any currency. Invoices and pay slips too.
Fills the Category column the moment extraction finishes. No second button, no separate step. Draws on 70+ categories across 13 groups, or your own. Correct one chip and it writes the rule forward.
Matches every bank line against your invoices and bills, marks the confident ones AUTOCLOSE, and routes the rest into a review queue with the evidence already attached. Partial, overpaid, unmatched and missing each get their own bucket.
Picks up what reconciliation could not close and explains why. Short payment, withholding tax, bank charges, wastage, part payment, duplicates, timing gaps: each one named, quantified and given a reason.
Pulls vendor and tax ID, line items with HSN, quantity and rate, tax, payment terms and due dates. It also raises your sales invoices. One born inside EkCell arrives already structured.
Builds filing packs out of reconciled data, not out of a fresh spreadsheet. The tax layer is pluggable by country, whichever regime you file under.
Timestamps every system action and every human decision, carrying both sides of a match so an entry is traceable from either end. Nothing is ever edited. A second decision appends a second entry.
Ask in plain language (who hasn't paid us, what's due this week, are we short next month) and get a structured answer card, not a paragraph. Cash runway runs off the real bank feed plus open payables and receivables.
Documents go in one end, a closed month comes out the other, and every step hands the next one something it can check.
Most tools tell you they matched 90% automatically and leave you to take it on faith. EkCell attaches the source to the entry itself, so checking a number is one click, not an afternoon with a folder of PDFs.
| Date | Particulars | Debit | Category |
|---|---|---|---|
| 09 Mar | AWS INV 40218 | 38,350 | Cloud |
| 12 Mar | RTGS DR-VERTEX | 6,37,200 | Raw Materials |
| 15 Mar | SALARY BATCH | 9,84,500 | Payroll |
| 18 Mar | TAX PMT-06 | 1,42,880 | Tax |
The statement stays open beside the transaction, so I am not switching windows to check a number. That is the part QuickBooks makes me work for. It also handles matching several invoices at once better than what I use now.
SAP, Oracle and QuickBooks all automate document routing and GL coding. That does not make them accurate. Someone still reviews and reconciles by hand, especially on client-specific revenue mapping.
Seeing the uploaded document next to the extracted lines is very helpful for validation. In Tally I key in every line by hand first, then go back to the file to check it. That is the half of the day I want back.
It matched the PDF invoice to the bank payment. For that to hold up generally, the invoice and the payment have to live in the same system, otherwise you are guessing at the join.
It does not only auto-reconcile. When a line does not match it tells you the reason it did not, and that is the part that makes review quick. I read the reason, agree or disagree, and move on. Approvals attaching to the transaction rather than the project is the other thing that matters to us.
No. The month arrives finished, and your job is to review it. EkCell reads, codes, matches and closes everything, then puts it in one queue with the evidence already open on each item. You approve. If your business needs tighter control, sign-off limits and second signatures are there to switch on. But the default is simply: we do the work, you say yes.
No. EkCell works on top of Tally, Zoho Books, QuickBooks, Xero, NetSuite or Sage rather than replacing them. It reads your banks and mailbox, does the month's work, and writes back into the system you already keep your books in.
It goes red and says so. An uncategorized line shows an "+ Assign" chip rather than a confident guess. The moment you assign it, the rule carries forward to matching transactions in future months.
It prepares them. The Tax & Filings Analyst builds VAT returns, sales-tax filings and other regional tax workings out of already-reconciled data and hands you a download pack. You or your accountant review and file. The submission stays a human act.
Any of them. The core (bank feeds, extraction, categorization, reconciliation, reports) is jurisdiction-neutral and multi-currency, so it runs wherever you keep your books. Tax is the only country-specific layer, and it is pluggable to whichever regime you file under, wherever that is.
Not to run it. The interface is a spreadsheet, not a chart of accounts. You read rows, check chips and approve matches. The double-entry underneath is generated for you, and it's there in full when your accountant wants to look.
In your own workspace, isolated to you. Everything is encrypted at rest, and nothing you upload is ever used to train a model, yours or anyone else's. Connectors authorise per user, and for the most sensitive work documents can be processed locally without ever being uploaded.
Click it. The bank line and the document open side by side, the matched amount is highlighted on the source page, and the basis of the match is stated in plain language. Checking is one click. That is the entire design premise.
Five steps. Get the statement into rows you can sort. Get the invoices into a list with number, date, party and amount. Match on amount plus party plus an open bill, not on amount alone. Explain every line that did not match, because that residue is the actual work. Then check that opening balance plus the period's movement equals closing balance, on both sides. EkCell does steps one to three and drafts step four, then hands you the exceptions.
Usually one of eight things: a short payment, tax deducted at source, bank charges netted off, a part payment against one invoice, the same bill entered twice, a timing gap across the month end, foreign exchange on the settled amount, or an internal transfer between the company's own accounts counted once instead of twice. Internal transfers are the most common and the least suspected.
It can do the reading, coding and matching, and it is genuinely good at those. It cannot tell you it is right. That is the gap that matters, because an unverifiable number costs more to check than to produce yourself. The accountants who tested EkCell said the same thing in different words: automation is useful for patterns, and a human still has to decide the odd ones. So the design assumption is not that the model is always correct. It is that every figure stays one click from the document it came from, which makes checking cheap enough to actually do.