Bank Feed and Reconciliation Automation

The month-end problem this solves

Zoho Books ships direct bank feeds, but the aggregator coverage behind them is uneven. If your bank sits outside North America or Western Europe — a Gulf commercial bank, a Pakistani or Indian scheduled bank, an African or South-East Asian institution, a payment gateway settlement account, a stablecoin or PSP wallet — the feed either does not exist or drops out for days at a time. The finance team ends up downloading CSV, XLS, MT940 or CAMT.053 files, reshaping them by hand, importing them into the Banking module, and then clicking through hundreds of transactions in the Match/Categorize screen because Zoho's built-in matcher only recognises near-exact amount and date pairs.

The pain compounds in three specific places. Split payments: a customer clears six invoices with one wire, so the built-in matcher offers nothing and the accountant reconciles manually. Bank charges and FX: the deposit is 1,987.40 but the invoice is 2,000.00, and the 12.60 difference must be posted to a charges account before the match will complete. Multi-entity groups: three Books organizations, three chart-of-accounts variants, and no shared rule set, so every entity's rules are rebuilt from scratch and drift apart.

ECOSIRE builds a reconciliation layer that closes those gaps inside your own Zoho org.

What ECOSIRE builds

Statement ingestion that accepts your bank's actual file

We build a Zoho Creator application that acts as the ingestion front door. It accepts the formats your banks genuinely emit — delimited CSV with inconsistent headers, XLS/XLSX exports, fixed-width text, MT940, and CAMT.053 XML — and normalises them into a canonical statement-line record: value date, booking date, description, reference, debit, credit, running balance, currency, counterparty where present. Column mapping is stored per bank account as a reusable profile, so a treasurer configures a bank once rather than remapping every upload. Where a bank publishes an API or delivers statements by SFTP or email attachment, we build a Zoho Flow scheduled fetch so the file lands without anyone touching it.

De-duplication runs on a composite hash of date, amount, reference and balance, so re-uploading an overlapping statement period never double-posts.

A matching engine written in Deluge

On top of the normalised lines we build a scored matching engine as Deluge custom functions, invoked from a scheduled function and from a manual Run Matching button in the Creator app. It reads open records through the Zoho Books REST API — invoices, bills, customer payments, vendor payments, expenses, existing bank transactions — and scores candidates on:

• amount proximity, with a configurable absolute and percentage tolerance
• date proximity within a rolling window you set per bank account
• token overlap between the statement narration and the contact name, invoice number, PO number or payment reference, with normalisation for punctuation, bank-inserted prefixes and truncated narrations
• historical behaviour: how this counterparty's descriptions have mapped in previously confirmed matches

Anything above your auto-confirm threshold posts through the Books API. Anything in the middle band is queued for one-click human confirmation with the top three candidates ranked and the reasoning shown. Anything below is left untouched.

Split, partial and many-to-many handling

One receipt against many invoices, many receipts against one invoice, and partial settlements are handled as first-class cases. The engine proposes an allocation set, applies it as a Books customer payment with multiple invoice allocations, and writes the residual — bank charge, FX difference, withholding tax, gateway commission — to the account you nominate per rule, so the transaction reconciles cleanly instead of sitting as an unapplied credit.

Categorisation rules for everything that isn't an invoice

Recurring non-invoice lines — bank charges, standing orders, utility direct debits, salary transfers, gateway settlements, inter-company sweeps — are handled by a rule table you maintain: match on description pattern, amount range, counterparty or transaction type, then post to a chosen account with a chosen tax treatment, vendor, customer, project or reporting tag. Rules carry a priority order and can be scoped to one bank account, one Books organization, or shared across the group.

Reconciliation control and exceptions

A reconciliation workspace shows, per bank account and per period: opening balance, statement closing balance, Books ledger balance, matched value, unmatched count, and the variance between them. Unreconciled items are aged, so a stale line from two months ago is visible rather than buried. Every automated posting writes an audit record — statement line, chosen rule or score, the Books record ID created, timestamp and user — so an auditor can trace any entry back to its source line.

Multi-entity and multi-currency

Where you run several Books organizations, we build the rule set as a shared library with per-organization overrides, and route each statement to the correct organization from the bank account profile. Foreign-currency accounts use the exchange rate on the Books transaction, with the FX gain or loss posted to the account you specify.

Who this is for

Finance teams closing monthly books in Zoho Books where bank feeds are unavailable, unreliable or incomplete; groups running several Books organizations that need one consistent rule set; e-commerce and services businesses reconciling payment-gateway settlement files where one payout covers dozens of orders net of commission; and any team where an accountant currently spends days each month in the Match/Categorize screen.

How delivery works

1. Scoping call. We review your bank accounts, sample statement files, chart of accounts, Books edition and organization structure, and the categories of transaction you want automated. You send two or three real statement files and a matching Books period.

2. Fixed quote. You receive a written scope covering supported formats, matching rules, split handling, entities and currencies, with a fixed price and a delivery date. Nothing starts until you approve it.

3. Build. We develop the Creator application, Deluge functions, Books API integration, Flow automations and rule tables against a sandbox or a test Books organization, using anonymised copies of your statement files.

4. Install in test. We deploy into your test environment, run your real statement history through it, and tune tolerances and rules with your accountant until the auto-match rate and the false-positive rate are both acceptable to you.

5. Production. We install into your live Zoho org, configure bank account profiles and rules, and run the first live reconciliation cycle alongside your team.

6. Support. A defined support window follows go-live for defect fixes, rule tuning and questions, with an optional extension.

Typical lead time is two to four weeks from approved quote, depending on how many banks, formats and entities are in scope.