Paying Bills from Inside Odoo 20: The PISP Payment Flow

For years, paying a vendor bill in an ERP ended one step too early. The bill was received, coded, approved and marked ready in the system — and then someone opened a separate banking portal, re-keyed the vendor, the amount and the reference, authorised the payment there, and later matched whatever came back on the statement to the bill that started it all. Every hand-off between the ERP and the bank was a chance for the amount, the account or the reference to drift. Odoo 20 closes that gap: bills can now be paid directly from Odoo, individually or in batches, with a single signature, through the new PISP interface.

PISP stands for payment initiation service provider. A PISP is a third-party service authorised to initiate a payment from a bank account at the account holder’s request — the user stays in the application where the work lives, gives the required authorisation or signature, and the provider instructs the bank to move the money. Odoo 20 builds that model into Accounting, so the payment run and the bills it settles finally live in the same place.

Diagram of bills flowing from approval through a single signature to bank payment via a payment initiation provider

The old flow, and where it broke

It helps to be precise about what changes, because Odoo has always been able to register a payment. Registering records the fact and the amount in the books; it does not, by itself, move money at the bank. Teams bridged the gap in a few familiar ways, each with its own weakness:

  • Re-keying in the bank portal. The approved figures in Odoo are typed again into online banking. A transposed digit, a wrong vendor account chosen from a similar name, or a stale amount after a last-minute bill edit produces a real payment that does not match the approved bill.
  • Batch payment files. Odoo can group payments into an electronic file — formats are region-specific, such as SEPA in Europe or NACHA in the United States — that someone downloads, uploads to the bank, and authorises there. The file flow works, but the file is a copy that leaves the system: edit a bill after generating it, and the file no longer represents what was approved.
  • The reconciliation tail. However the money moved, the resulting bank transaction still had to be matched back to the bill. When references were re-keyed or shortened along the way, matching became manual detective work.

Together, these steps mean the moment of actual payment — the one irreversible step — historically happened outside the system that held the approval, the amount and the audit trail.

The Odoo 20 PISP flow, step by step

The release notes state the feature in one sentence: pay bills individually or in batches, with a single signature, directly from Odoo via the new PISP interface. Unpacked into a working payment run, the flow looks like this:

  1. Prepare and approve the bills as before. Bills are entered, coded and posted through the normal accounting flow. Nothing about PISP changes who approves a bill or what “ready to pay” means in your process; it changes what happens next.
  2. Select what to pay. Pay a single bill on its own, or select a set of due bills for a batch run — the way most finance teams already organise supplier payments, by due date and cash position.
  3. Review the payment as a whole. Because the payment is initiated from the bills themselves, the amounts, vendors and references are the ones on the approved records — not a re-typed summary of them.
  4. Sign once. The person authorised to release payments signs the batch with a single signature through the PISP interface, rather than authorising each payment separately in a bank portal. One signature for the run is the headline efficiency: the review happened in Odoo, and the authorisation now happens on the same data.
  5. The provider initiates the payments at the bank. The PISP carries the instruction to the bank, and the funds move from the company account to the vendors.
  6. The payment lands back in the accounting flow. The bills settle against the resulting bank transactions in the normal reconciliation process — now with references that originated in Odoo instead of being copied into it.

The exact screens, authorisation method and provider steps depend on the PISP and the bank involved, so treat the list above as the shape of the flow rather than a click-by-click script for your own account. What is new and fixed is the architecture: initiation, review and signature happen inside Odoo, on the bill records themselves.

Why a single signature matters more than it sounds

Batch payment with one signature is easy to read as a small convenience. In a weekly payment run it is a control improvement. When each bill is authorised separately in a bank portal, the authoriser is effectively re-approving payments one by one, usually quickly, usually from a list that no longer shows the bill detail behind each amount. Fatigue sets in, and approvals become rubber stamps.

Bringing the run into Odoo reverses that. The finance team prepares and reviews the batch where the bills, amounts, due dates and vendor details are fully visible, and the signatory signs the reviewed batch once. The division of labour becomes clean: preparation and checking where the data is rich, authorisation as one deliberate act on a set that was checked as a set — instead of stretching the bank portal into a second, weaker approval system.

Controls that travel with the new flow

Paying from inside the ERP raises an obvious question: what stops a wrong or duplicate payment from leaving faster? Two neighbouring Odoo 20 changes are relevant here.

First, the payment wizard now guards against double payments directly: it detects pending payments, automatically deducts them from the amount due, and sorts outstanding payments by date for a clearer timeline. Payment statuses were also renamed for clarity — what was “In Process” is now “Paid”, and what was “Paid” is now “Reconciled” — so a bill with money already on its way is harder to mistake for an unpaid one. In a batch context, that visibility is the difference between paying a bill once and paying it in two overlapping runs.

Second, Odoo 20’s bank consistency rule tightens the other end of the loop: every journal entry affecting a bank account must originate from a bank transaction, and manual entries on bank accounts are no longer allowed. A PISP-initiated payment therefore cannot quietly exist only as a bookkeeping entry — it has to reconcile to a real bank movement, and the new reconciliation summary report gives finance a period-end view of what matched and what is still outstanding. Initiation inside Odoo plus reconciliation against real bank data is a tighter loop than either half alone.

Your existing internal controls still apply and still matter: vendor bank details must be correct and changes to them controlled, the person signing should not be the only person who prepared the run, and batch totals deserve the same sanity check against cash position they always did. PISP removes transcription risk between approval and payment; it does not remove the need for the approval itself.

Availability: the honest caveat

A PISP flow depends on parties outside Odoo: the provider offering the interface and the bank holding the account both have to support payment initiation for your account and your country. Support for this kind of bank connectivity varies by region, by bank and by provider, and it changes over time. This article therefore makes no claim that a specific bank or country is covered today.

Before planning around the feature, verify three things for your own setup: whether a PISP option is offered for your Odoo database and localisation, whether your bank supports payment initiation through that provider for business accounts, and what authorisation method — app approval, hardware token, or another strong authentication step — the signature will require in practice. Run a first live test with one small bill to a familiar vendor, confirm the money moves and the transaction reconciles cleanly, and only then move the weekly run over.

Who gains, and who should wait

The clearest winners are teams with a real payment cadence: manufacturers and distributors paying many suppliers weekly, multi-entity businesses running separate runs per company, and any finance team whose month-end pain is matching bank lines back to bills. For them, removing the portal re-keying step is a weekly saving, not a novelty.

Teams that pay a handful of bills a month, or whose bank cannot yet support initiation, lose nothing by waiting: registering payments and using batch files remain available. The PISP flow is an addition to the payment toolkit, not a forced migration. But when bank and provider line up, it completes a loop Odoo users have wanted closed for years — the bill is approved in Odoo, paid from Odoo, and reconciled in Odoo, with one signature and no re-keyed numbers in between.

Further reading

Leave a Comment