Requirements

• The pyjwt Python library must be installed in the server (declared as external dependency of the module; the JWT is signed with RS256).

• A public HTTPS URL for Odoo reachable by the browser that completes the bank authorization. Enable Banking validates the redirect URL against the registered list with an exact match, so web.base.url must hold the HTTPS URL of the instance: Odoo rewrites that parameter with the scheme of the last web request, so set web.base.url.freeze when the instance runs behind an HTTPS proxy. When the current request is already HTTPS the module builds the redirect URL from the request itself and does not depend on the parameter.

Register the Enable Banking application

1. Create an account and sign in at the Enable Banking Control Panel.

2. Register a new application in the desired environment (start with sandbox; restricted production for real bank accounts).

3. Enable Banking asks for a certificate: use the default one offered by the control panel or upload your own self-signed certificate.

4. The control panel shows the Application ID and lets you download the private key (PEM). Keep both.

5. In the application settings, add this Odoo instance’s redirect URL: https://<your-odoo-domain>/enable_banking/response (no trailing slash). The exact value is shown in the provider form (Enable Banking Redirect URL field). Enable Banking validates it against the registered list with an exact match: if the callback URL is missing, the authorization is rejected with REDIRECT_URI_NOT_ALLOWED.

Configure the provider

1. Open the bank journal (Accounting > Configuration > Bank Journals) and set Bank Statements Source to Online.

2. Open its online bank statement provider and choose Enable Banking as Service.

3. Fill in the Enable Banking group:

   • Application ID: value obtained when registering the application.

   • Private Key: PEM file downloaded when registering the application.

   • ASPSP Name: exact bank name as listed by Enable Banking (e.g. Caixa Guissona).

   • ASPSP Country: two-letter country code of the bank (e.g. ES).

   • PSU Type: Business for company accounts, Personal otherwise.

4. Click Connect and complete the authorization in your bank; the account is linked when the bank redirects the browser back to Odoo.

Scheduled pull

Banks limit how many background fetches an application can make per day (many ASPSPs allow around 4). The pull interval defaults to 1 day; keep a daily (or slower) schedule. When the bank answers a rate limit error, the pull is logged on the provider and deferred to the next scheduled run.

When the authorization is about to expire (15 days warning is displayed), use Reconnect to renew it. The maximum consent validity depends on the bank and is usually 180 days.

De-duplication

Statement lines are de-duplicated with the transaction identifier the bank provides (entry_reference). Some banks do not return any identifier at all: for those, the module builds a deterministic digest of the transaction content, so pulling the same period twice does not duplicate the lines. Identical operations of the same pull are kept apart with an occurrence index, so repeated transactions are never dropped either.

Repairing a journal imported with an older version

A journal that already imported operations before this fallback existed keeps lines without identifier, and usually the same operation several times. The bundled script repairs it in place:

EB_DEDUPE_PROVIDER_ID=<provider id> odoo shell -d <db> --no-http < scripts/dedupe_statement_lines.py

1. The first run is a dry run: it lists the repeated groups and how many lines would be deleted or identified, and it stops there.

2. Add EB_DEDUPE_APPLY=1 to the same command to delete the extra copies and write the identifiers. The script reads the operations from Enable Banking through the module itself, so the identifiers it writes are exactly the ones the next pull expects.

3. Start one pull afterwards to refresh the statement balances.

An operation can legitimately be repeated the same day with the same amount and reference, so a line is only deleted when the bank returns fewer copies than the journal holds. Lines whose operation the bank no longer returns are left untouched unless EB_DEDUPE_TRUST_CONTENT=1 is passed.

What the script never touches:

• journals of other banks: only the journal of the provider passed in EB_DEDUPE_PROVIDER_ID is read, the rest of the database is never scanned;

• lines outside the reviewed window (EB_DEDUPE_DAYS, 180 days by default), so older statements are not affected;

• lines that already carry an identifier;

• lines created by hand: they belong to no statement and are only counted in the report;

• reconciled lines: they are never deleted, and when a group contains a reconciled copy that copy is the one kept and identified.

Authors

• SomIT Cooperatiu SCCL

Contributors

• Nicolás Ramos <nicolas.ramos@somit.coop> (https://github.com/nicolasramos)

Maintainers

• Nicolás Ramos (https://github.com/nicolasramos)

This module is built on top of the OCA modules of the bank-statement-import project.