Odoo bank synchronization and reconciliation

The bank feed is not a file your server downloads on its own. In Odoo's bank synchronization design, the connection to a bank is set up through a synchronization service that Odoo operates, and the transactions it retrieves are delivered into the bank journal you configured in Accounting. From there, Odoo stores them as bank statement lines, ready for matching against invoices, bills and other open items. Your team should understand this path before approving the design, because each hop has a different owner and a different failure mode.

The network path is a planning item. A self-hosted Odoo server cannot receive bank data unless it can reach the synchronization service endpoints over the network. That means outbound connections from the server, and possibly from a reverse proxy or egress gateway in front of it, must be allowed to specific destinations. If your organization restricts egress by default, which most regulated environments do, the firewall rules, proxy exceptions and DNS resolution for those endpoints need to be designed with your network security team before the connection is tested. Confirm with Odoo which endpoints a self-hosted deployment needs, whether they change over time, and how certificates and ports are handled, and record the answer in your network change request.

Ask Odoo which providers sit behind the service. Bank connections in Odoo are often brokered by third-party data aggregators, and the provider can differ by country and by institution. Ask Odoo to confirm, in writing, which providers are used for each country where your entities hold accounts, and whether any bank credentials, account identifiers or transaction data pass through systems outside your network under that design. Your data protection and treasury teams will need that answer to assess the data flow, and it may also determine whether the connection is permitted for certain accounts at all.

Check what leaves your network and what stays. Even with a self-hosted server, the bank connection may involve data processed on Odoo's side or on a provider's side. Map each data element (credentials or tokens, account numbers, balances, transaction descriptions, counterparty names) to where it is processed and stored, and to the retention rules that apply. If the answers do not fit your data residency or outsourcing policy, the choice is between a different connection method, a manual statement import, or a documented exception approved by the accountable owner. Do not assume that a self-hosted database means the bank data stays inside your perimeter.

A reconciliation model in Odoo Accounting is a set of rules that the bank reconciliation widget applies to each imported bank statement line before anyone touches it. Each rule states the conditions a line must meet, such as a partner name or fragment, a word or pattern in the label, an amount or amount range, or an invoice reference that appears in the payment text. When a line satisfies a rule, Odoo proposes the counterpart entries that rule defines, such as an open customer invoice, a vendor bill or a write-off account. Whether those proposals are applied automatically depends on how the rule and the journal are configured. The first decision is therefore not which rule is most accurate, but which lines you want the system to decide without a person looking at them.

Rules are evaluated in sequence, and the order matters. A broad rule near the top can claim lines that a narrow rule, such as one matching an invoice reference, would have matched more precisely. Review the sequence against a sample of real statement lines from each bank journal, and keep rules that depend on exact references ahead of rules that depend on partial labels or amounts. Lines that no rule matches stay in the reconciliation list for manual handling. Leaving those lines for review is the correct outcome for payments from unknown counterparties, split payments, bank fees bundled into a single credit, and foreign currency differences. Forcing a rule to cover them usually shifts errors into the ledger rather than removing them.

The trade-off is between match coverage and the risk of posting to the wrong partner. A looser rule, for example one that matches on a partial name or a common label prefix, will match more lines but can attach a payment to an invoice from a different customer who shares a similar name or paid a similar amount. Those errors are not always visible in the bank journal balance, so they surface later in aged receivables or in a supplier statement dispute. Do not enable automatic validation on a model until you have seen how it behaves on your own data. Run the models in suggestion mode for a defined test period that covers several month-end closes, including at least one period with refunds, partial payments and returned transfers.

During the test period, measure the match rate for each model and each journal, and sample the automatic proposals against source documents. Record how many proposals a reviewer would have corrected, which partners were affected and which rule produced each error. Those figures, not a vendor or partner estimate, should decide which rules you allow to validate automatically. Agree the criteria in writing before the test starts: the accepted error sample size, the reviewer who signs off, and the rules that stay in suggestion mode. Ask your implementation partner to document these criteria in the configuration record so that later rule changes go through the same check.

If your bank is not on the supported list, do not assume the project is blocked. Work through four fallback options in order, and validate each one on your exact Odoo version before you commit to it. The first step is to confirm the current list of supported institutions and providers in the Odoo documentation for your version, because coverage changes over time and a bank missing from a page you read last year may now be covered, or the reverse. Record the check with the date and the version, so the decision can be reviewed at upgrade time.

The second option is a documented statement import format. Ask your bank which export formats it can produce, such as a standard statement file, and compare them against the import formats Odoo documents for Accounting. If one matches, the work is mostly a mapping exercise: sample files from several months, checked for account numbers, currency, balance lines, and date formats. Test the import in a copy of the database first, because a format that looks compatible can still misread decimal separators or reference fields that reconciliation depends on.

The third option is a connector published on the Odoo Apps Store. Before installing one, confirm who publishes it, which Odoo versions it declares support for, what support terms apply, and whether it stores bank credentials or access tokens on your server. A third-party connector adds a dependency to your upgrade plan: it must be re-tested at each major version change, and its support may end before Odoo's own. Ask the publisher for written version compatibility and a clear statement of who fixes defects that affect your reconciliation.

The fourth option is a manual or scheduled file import under a controlled process. This is acceptable only if the business owners agree to the operating effort and the risks. Define file custody (who downloads the statement, where it is stored, and how long it is kept), a duplicate check so the same statement is never imported twice, and an approval step before reconciled entries are posted. Keep an import log that records file name, hash, period, and the user who imported it. Each of these controls is a design decision that should be written down before go-live, not left to individual users.

Whichever path you choose, validate it on your client's Odoo version before selecting it, including the Community or Enterprise edition in use and any modules it depends on. Test with real statement samples, confirm that reconciliation models still match the imported lines, and rerun the test after every planned upgrade. An option that works on one version can break on the next, so the validation result belongs in the project record alongside the bank list check.