Bank Statement Import and Auto Reconciliation

Where the month goes

Bank reconciliation in most SAP Business One installations is a manual sport. Someone downloads a statement from each bank portal, opens it beside SAP Business One, and works line by line: find the customer from a truncated narration, guess which of their six open invoices the payment covers, key an Incoming Payment, apply it, and move on. Multiply that by several accounts, two or three currencies, and a few hundred lines a month, and reconciliation becomes days of work that produces no insight — only the ability to close the period.

The cost is not only time. Unapplied receipts distort the ageing report, so credit control chases customers who have already paid. Bank charges and interest get lumped into suspense accounts. Partial payments and payments covering several invoices are the ones that get deferred to next month, and next month they are harder still.

SAP Business One ships bank statement processing, but the matching intelligence is limited: it will not learn that a particular narration always means a particular Business Partner, it will not split a single credit across four open A/R Invoices by reference, and it will not carry your bank's specific file quirks.

What ECOSIRE builds

ECOSIRE builds a per-tenant SAP Business One add-on that ingests your banks' statement files, applies a matching engine you control, and posts the resulting payments through the Service Layer with full audit back to the statement line.

Format handling built for your banks

We build parsers for the formats your banks actually issue: SWIFT MT940 and MT942, ISO 20022 CAMT.053 and CAMT.054, and bank-specific CSV or Excel exports. The last category matters more than it should — most regional banks emit a CSV with their own column order, date format, decimal convention and narration structure. Rather than pretending a generic importer will cope, we build a per-bank profile that maps columns, date and number formats, debit/credit sign convention, and the fields where a reference actually hides. Profiles are stored as User-Defined Objects so a bank changing its export can be re-mapped by configuration rather than a code change.

Statements can be dropped into a watched folder, uploaded through the add-on screen, or collected from an SFTP location your bank publishes to, depending on what your banks support.

The matching engine

Each statement line runs through an ordered rule set until something matches with sufficient confidence:

• Exact reference match — the narration contains an A/R Invoice number, Incoming Payment reference, or a payment reference you stamped on the document.
• Amount and Business Partner match — the credit equals a single open invoice for a Business Partner identified by bank account number, IBAN, or a learned narration pattern.
• Combination match — one credit covers several open invoices; the engine finds the subset of open documents that sums to the received amount within tolerance.
• Partial payment — the credit is less than the invoice, and the rule set decides whether to apply it as a partial payment or hold it for review.
• Non-invoice lines — bank charges, interest, transfers between your own accounts and FX differences are routed to the G/L accounts you nominate and posted as Journal Entries rather than payments.

Every rule has a confidence outcome. Lines above your auto-post threshold post without intervention; everything else lands in a review queue with the engine's best suggestions ranked, so the accountant confirms rather than searches. When a user manually matches a line, the narration pattern and the counterparty bank account are written to a learning table so the same payer matches automatically next time.

Posting and audit

Matched receivables post as Incoming Payments applied to the specific A/R Invoices, matched payables as Outgoing Payments against A/P Invoices, and non-trading lines as Journal Entries to the accounts in your profile. Each posted document carries the statement identifier, the line number and the rule that matched it in User-Defined Fields, so any posting can be traced back to the exact line of the exact file. Re-importing the same statement is safe: lines are fingerprinted, and an already-processed line is skipped rather than duplicated.

Where your policy requires a second pair of eyes, posting can be routed through SAP Business One approval procedures instead of committing directly.

Reconciliation close

We build a reconciliation screen that shows, per bank account and per period, the opening balance, imported lines, posted lines, lines still in review, and the resulting difference against the bank's closing balance — the single number a controller actually wants. Unresolved lines carry forward with their reason, and a Crystal Reports reconciliation statement is delivered for your auditors.

Who this is for

Any SAP Business One company with meaningful transaction volume across one or more bank accounts: distributors and retailers with many small receipts, manufacturers with high supplier payment volume, service companies with recurring collections, and groups holding accounts in several currencies. It is most valuable where the finance team is already spending multiple days a month on reconciliation, or where the ageing report is not trusted because unapplied receipts sit in it.

Technical fit

The add-on targets SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or cloud-hosted. Payments and Journal Entries are posted through the Service Layer, with the DI API where required for payment application behaviour. Bank profiles, matching rules, learned patterns and imported statement lines live in User-Defined Tables and are maintained through User-Defined Object screens. Statement identifiers and matching provenance are stamped on posted documents as UDFs, and reconciliation output is delivered as Crystal Reports layouts registered inside SAP Business One.

How delivery works

1. Scoping call. We collect sample statement files from each of your banks, review your open-item structure, your tolerance and rounding policy, the G/L accounts for charges and FX, and how much you want posted automatically versus reviewed.

2. Fixed quote. A written scope and a fixed price, issued before development starts. The number of bank formats is the main cost driver and it is stated explicitly.

3. Build. ECOSIRE builds the parsers, the rule set and the posting logic for your banks and your policy. Typical lead time is one working week from signed quote. Nothing is pre-built.

4. Install in test. We install into your test company database and replay several months of your real statements against your real open items, then compare the result against what your team posted manually. That comparison is the acceptance test.

5. Install in production. After sign-off we install into production, set the auto-post thresholds conservatively for the first cycle, and raise them once the match rate on your own data justifies it.

6. Support. A defined support window follows go-live for defects and rule tuning, with the terms stated in your quote. Bank format changes after that window are quoted as small change requests.