Every finance team running Odoo eventually hits the same friction: a customer with ten open invoices has to open the portal, click into each invoice separately, and run ten individual online payments. That means ten payment-provider transaction fees, ten account.payment records to reconcile, ten confirmation emails, and a frustrated customer who abandons half the payments midway. Out of the box the Odoo portal is built around the single-invoice view (/my/invoices/<id>) — the payment and account_payment flows key each transaction to one account.move, so there is no native "select several invoices and pay the combined balance at once" experience on the website. Teams work around it with manual bank transfers and spreadsheet chasing, which is exactly the reconciliation drag Odoo was supposed to eliminate.

This is what we build for you. Website Multi Invoice Payment is a portal extension that adds a bulk-selection layer over the customer's list of posted, unpaid account.move records. We inherit the portal account controller (PortalAccount / http.Controller) so the logged-in customer sees checkboxes plus a live "selected total" that we compute from amount_residual, scoped by move_type in ('out_invoice','out_refund') and payment_state in ('not_paid','partial') and filtered by the portal record rules so a partner only ever sees their own documents. A single "Pay selected" action assembles the chosen invoices into one payment intent and hands it to Odoo's standard payment engine, so the money moves through whichever acquirers you already have configured (payment.provider) with no bespoke gateway code. On success we generate the payment, post it, and let Odoo's reconciliation match it against each selected account.move — optionally splitting a single received amount across invoices oldest-first when a partial-allocation policy is requested.

Technically, the module ships as a proper addon: a __manifest__.py declaring dependencies on account, account_payment, payment, portal, and website; new/extended models with @api.depends compute fields for the running selection total and eligible-invoice domain; QWeb templates that extend the existing portal invoice list rather than replacing it (so your theme and any other portal customizations survive); and ir.model.access.csv plus record rules that keep the multi-select strictly inside the requesting partner's commercial entity. We wire the confirmation and receipt into the standard mail templates, expose the bulk-pay result over the JSON-RPC/XML-RPC layer for any headless or app integration you run, and cover both Community (manual/wire acquirers) and Enterprise (full electronic-payment acquirers, follow-up automation) so the feature behaves correctly on your edition. Everything is delivered against your pinned series — 17.0, 18.0, or 19.0 — with the controller and template inheritance adjusted for the API differences between them.

Because this is build-to-order, nothing is pre-listed for instant download: after a short scoping call we confirm the exact selection rules, allocation policy, and acquirer set, then build, test on a staging clone of your database, and install to production. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company deployments, additional payment acquirers or currencies, partial-allocation logic, and localization or e-invoice reconciliation requirements increase the quoted scope — you receive a fixed quote after the scoping call, never a surprise invoice.