Payment Allocator
You decide how much goes to each invoice, not the order of the list
Splits a single vendor payment across several open invoices, by amount or by percentage, and creates the real accounting reconciliations. It solves the consolidated payment that Odoo can only apply one full invoice at a time until the money runs out.
How you get it
Every development works in all three Odoo environments. The only thing that changes is how we deliver it.
Odoo Online (SaaS)
You do not need the ability to install modules. A Millora consultant comes in with temporary access that you authorize and implements it with Odoo Studio. When they are done, you revoke the access.
Odoo.sh or your own server
You receive the module and the installation guide by email as soon as payment clears. Install it yourself, or we install it with you.
Installation · shell
# 1 · copia el módulo a tu addons_path
cp -r millora_aplicador_de_pagos /mnt/extra-addons/
# 2 · reinicia y actualiza la lista de apps
odoo-bin -u all -d tu_base --stop-after-init
# 3 · instala desde Apps
# busca "Payment Allocator"What it solves
The problem
A vendor invoices you for every delivery and you pay them once a month, in a single transfer. The payment doesn't match one invoice: it matches a slice of several.
Odoo doesn't know how to split. When reconciling, it settles whole invoices one by one, in whatever order it takes them, until the money runs out; the remainder lands on the next available invoice, which is almost never the one you meant. If what you negotiated was paying 40% of three invoices, there is nowhere to write that down.
The usual way out is doing it by hand in accounting, entry by entry. It works, it is slow, and it is the kind of task where one wrong digit stays hidden until the vendor sends their statement and the balances don't match.
How it works
You pick the vendor and a payment that still has an unapplied balance. The screen pulls in their open invoices and you decide, line by line, how much goes to each one: by amount or by percentage, whichever is closer to the deal you actually made.
On confirmation, that split becomes real accounting reconciliations. Not a parallel record, not a note of what was intended: each invoice ends up with the balance it should have and the payment with whatever is left to apply, exactly as if it had been reconciled by hand.
Before letting you confirm, it checks what usually goes wrong: that you are not allocating more than the payment holds, that no line exceeds its invoice's balance, and that no draft, unposted or already settled invoice slips in.
Every allocation is stored with its state — new, applied or cancelled — its company, its currency and who last changed it. So when somebody asks why that invoice ended up with that balance, the answer is one screen instead of an archaeology of journal entries.
If the payment is in one currency and the invoices in another, it converts using the rates loaded in the system. And in databases with several legal entities, each operation stays inside its own company: a vendor that invoices two companies in the group never gets crossed.
What it does not do
One allocation, one vendor. It does not mix invoices from different vendors into the same payment.
The whole split is manual, and that is the point. There are no automatic "oldest first" rules or anything like them: the entire development exists so the decision stays yours. If what you want is the system deciding for you, this is not it.
It takes no negative amounts and does no reverse reconciliations, it does not touch draft or unposted invoices, and it will not open a payment that is already fully reconciled.
Currency conversion is only as good as the rates you have loaded. If today's rate is not in the system, the allocation will show it.
What changes
The split was already decided before anyone opened Odoo — agreed on the phone with the vendor, or worked out in a spreadsheet. What changes is that it now gets entered as it stands, in a minute, instead of being translated into journal entries by hand.
And each invoice's balance stops depending on the order Odoo happened to walk through them.
What's included
- Splits one payment across several of the vendor's open invoices, partially or in full
- Sets how much goes to each invoice by fixed amount or by percentage
- Creates real accounting reconciliations, not a parallel record
- Blocks allocating more than the payment holds or more than an invoice's balance
- Leaves out draft, unposted and already settled invoices
- Stores every allocation with its state: new, applied or cancelled
- Records who last modified each allocation and when
- Converts automatically when payment and invoices are in different currencies
- Keeps each operation inside its own company in multi-entity databases
Requirements
- Accounting module active
- Posted invoices with an outstanding balance: drafts do not enter the allocation
- A registered payment with an unapplied balance. The allocator splits existing payments, it does not create them
- Up-to-date exchange rates if you will allocate across invoices in another currency
You might also need
AutoAzur Global Invoice Reconciler
One global CFDI, hundreds of orders, one run
Accounting & tax
Aspel NOI payroll import
The payroll you already filed lands in Odoo as a journal entry
Accounting & tax
Company Color Bar
Know which company you're in at a glance
Administration

