Automated Bank Feeds & Reconciliation

The pain

Month-end close waits on cash. Somebody downloads a CSV from each bank portal, reshapes it into the layout NetSuite's import expects, loads it, and then hand-ticks hundreds of statement lines against Customer Payments, Vendor Bill Payments, Deposits and Journal Entries. Bank charges, interest, standing orders, FX fees and transfers between your own accounts have no NetSuite counterpart at all, so each one becomes a manually keyed Journal Entry that somebody has to remember to code the same way as last month.

The symptoms are familiar: a reconciliation that is always a week behind, a bank account whose NetSuite balance and real balance diverge for reasons nobody has time to trace, duplicate imports after a re-run, and an intercompany transfer counted twice because it appeared on two statements.

What ECOSIRE builds

ECOSIRE builds a NetSuite customization for your account, wired to the feed source you actually have, delivered as an SDF project / unmanaged bundle you own.

Feed ingestion

Transactions land in NetSuite one of two ways, and we build whichever fits your banks. Either a Scheduled Script calls an aggregator's REST API on a cadence and pulls transactions per linked account, or a RESTlet accepts pushed transaction batches and a file-based lane parses statement files (CSV, OFX/QFX, MT940, CAMT.053) dropped into the File Cabinet. Every ingested transaction becomes a row on a custom record — for example customrecord_eco_bank_txn — carrying the bank account, posting and value dates, amount, currency, description, counterparty, bank reference and a deterministic hash used for deduplication. Re-running an import is safe by construction: the hash prevents a second copy.

Matching engine

A Map/Reduce script runs the unmatched rows against a rule ladder you define during scoping. Typical strategies, in order: exact match on a bank reference or payment reference written by NetSuite onto the payment; match on an EFT or check number carried in the statement description; exact amount plus date-window plus bank account against open Customer Payments, Deposits or Bill Payments; grouped match where one statement credit clears several payments (a batched deposit); and split match where one NetSuite transaction is settled by multiple statement lines. Each match records which rule fired, so a reviewer can audit the logic rather than accept a verdict.

Rule-driven posting for lines with no counterpart

Bank charges, interest, FX fees, standing orders and payroll debits do not correspond to an existing NetSuite record — they need one created. A rule record (customrecord_eco_bank_rule) lets you express conditions on description, counterparty, amount range, sign and bank account, and an action: create a Journal Entry to a nominated account with department, class, location and custom segment defaults; create a Vendor Bill Payment against a standing vendor; or flag for review. Rules are versioned and can be run in a dry-run mode that shows what would post without posting it.

Internal transfers

Money moving between two of your own bank accounts shows on both statements. The app detects the counterpart line — opposite sign, matching amount, within a date window, both accounts in your configuration — and posts a single Transfer record, marking both statement lines as cleared. That single behaviour removes one of the most common causes of double-counted cash.

Reconciliation and close

Matched lines mark the corresponding NetSuite transactions as cleared with the statement date, so NetSuite's own Reconcile Account Statement page opens with the work already done and a reviewer confirms rather than performs it. A Suitelet workbench shows, per bank account and period, the opening balance, cleared total, uncleared NetSuite transactions, unmatched statement lines and the resulting difference — the single number a controller actually wants. A SuiteFlow workflow escalates lines unresolved past a threshold you set.

Multi-account, multi-subsidiary, multi-currency

Each bank account is a configuration record mapped to its NetSuite bank account, subsidiary and currency. Under OneWorld the correct subsidiary context is applied on every posting. Foreign-currency accounts reconcile in the account currency, with revaluation left to NetSuite's own process rather than being silently fudged into a fee account.

Who this is for

Any NetSuite tenant reconciling more than a handful of bank accounts by hand — most acutely finance teams with multiple entities, multiple currencies, or a high volume of small receipts where the manual tick-and-tie is the entire bottleneck in close.

How delivery works

1. Scoping call. We list your banks, how you can get data out of each one (aggregator API, direct file, portal export), your reconciliation policy and your chart of accounts for charges and interest. 2. Fixed quote. A written scope covering the feed lanes, the rule set, the matching ladder and the workbench, at a fixed price. 3. Build. SuiteScript 2.1 Scheduled, Map/Reduce, RESTlet, User Event and Suitelet scripts, plus custom records, saved searches, roles and a SuiteFlow escalation, assembled as an SDF project. 4. Install in your sandbox. Deployed to sandbox and replayed against several months of your real statements so you can compare its matching to the reconciliation you already signed off. 5. Production. Same bundle deployed to production once you approve the sandbox results, followed by a supervised first close. 6. Support window. A defined post-go-live period for defects and feed-format changes, with all source in your account.

Lead time is typically 2–4 weeks from signed quote, driven mostly by how many distinct feed formats and banks are in scope.

What we will tell you honestly

The quality of any bank reconciliation depends on what your bank actually puts in the statement description. Banks that supply a structured remittance reference reconcile close to hands-free. Banks that supply a truncated free-text blob will always need more human review, and we will say so during scoping rather than after go-live.