Odoo 19 replaced Create Bill with Upload — and that's the right call
Odoo 19 dropped the Create Bill button on confirmed POs in favour of an Upload action. Here's why that's correct, and how to bring the old click back if you must.
If you upgraded to Odoo 19 and stared at a confirmed purchase order looking for the Create Bill button, it isn’t hiding. It’s gone. The new flow gives you an Upload Bill action that takes the actual supplier PDF (or image, or email body) and asks the OCR service to draft a vendor bill from it. No source document, no payable.
This is correct. The forum threads asking how to put the old button back are solving the wrong problem. The right answer is to change how your AP team works, with one small carve-out for the cases where the new flow genuinely doesn’t fit.
What actually changed
On a confirmed PO in 18.0, you’d click Create Bill and Odoo would generate a draft account.move with the PO lines pre-filled. You’d then save it, post it, and pay it. The source document — the supplier’s actual invoice — was an attachment you might or might not get around to uploading.
In 19.0, the button on the PO form is now Upload Bill. It opens the standard bill-upload modal, runs the document through Odoo’s OCR (the IAP service — free tier is limited, then it’s per-document credits), and produces a draft bill linked back to the PO. The PO lines are still used to suggest matches; the OCR populates the rest. You review the draft, fix anything OCR got wrong, and post.
The old action still exists in the backend — it’s just no longer wired to a button on the form view. We’ll come back to that.
Why this is the right default
The job of a vendor bill is to say “the supplier sent us this, and we owe them for it.” If you can post a bill without the supplier’s invoice in your hands, you’ve built an AP process where the system’s record and the supplier’s record can drift, and nobody notices until reconciliation breaks.
Forcing the source document up front fixes four things that are quietly broken in a lot of Odoo 17 and 18 installs:
- Audit trail matches reality. Every posted bill has the document the supplier actually sent attached to it. No more “the PDF is in someone’s inbox” answers during audit.
- Duplicate detection works. Odoo’s duplicate-invoice warning is keyed off vendor reference and date — fields that OCR fills in from the PDF. If the AP clerk types the reference manually, they type it differently every time and duplicates slip through.
- Three-way match becomes possible. PO, receipt, invoice — the third leg of that stool needs the invoice to physically exist. Click-to-create skips it.
- Disputes get easier. When the supplier says “you owe us extra freight,” you can pull up the document they sent and check.
This is how auditors expect AP to run. Odoo finally agrees.
The valid pushback
There are three cases where the new flow gets in the way, and pretending otherwise would be dishonest:
- Small suppliers who email an Excel sheet or a Word table. OCR doesn’t love these. The draft it produces is usually wrong enough that fixing it is slower than typing the bill manually.
- Recurring service invoices with no PDF. The cleaner who comes every Tuesday, the SaaS subscription that’s billed by a debit on the bank statement, the intercompany allocation. There is no document because there was never one.
- Bulk back-entry. Migrating opening AP balances, or catching up on a month of bills after a holiday, you don’t want OCR in the loop.
For these, you need the old behaviour. There are four ways to get it.
How to bring the click back
1. Developer mode action shortcut. Turn on developer mode (Settings > General > Activate Developer Mode), then on the PO form, use the bug icon (⋮ debug menu) to run the underlying server action — the method is still action_create_invoice on purchase.order. This works for one-off cases. It’s not a daily workflow.
2. A tiny custom module. Twenty lines of XML re-add the button on the PO form, calling the same server method:
<record id="purchase_order_view_form_inherit_create_bill" model="ir.ui.view">
<field name="name">purchase.order.form.create.bill</field>
<field name="model">purchase.order</field>
<field name="inherit_id" ref="purchase.purchase_order_form"/>
<field name="arch" type="xml">
<button name="action_create_invoice" position="attributes">
<attribute name="invisible">0</attribute>
</button>
</field>
</record>
If your team has even one developer, this is the cleanest option. Install it on the workstations of the people who do the back-entry work; everyone else gets the new flow.
3. Stay on 18.0 LTS. 18.0 is supported through October 2027 for Enterprise. If your AP process genuinely cannot move to document-first, the LTS path buys you eighteen months to either change the process or build the module above. Don’t use this as “we’ll deal with it later” — use it only if there’s a real plan.
4. Server action for manual entry. Create an ir.actions.server that runs action_create_invoice and add it under Action on the PO form. Same effect as the custom module, no developer needed, configurable from Studio.
What I’d actually do
Adopt the new flow. Train the AP team to ask suppliers for PDFs — most already send them. For the 5% of cases that don’t fit (the spreadsheet suppliers, the recurring services, the migrations), use option 4 — a server action labelled clearly as Manual Bill Entry so anyone using it knows they’re stepping outside the default for a reason.
That gives you the discipline of the new flow for almost everything, an escape hatch that doesn’t require a custom module, and a name on the button that tells the next auditor exactly what happened.
The Create Bill button being gone feels like a regression on day one of the upgrade. Six months in, the bills with no attached document — the ones you used to inherit from a predecessor and couldn’t explain — stop appearing. That’s the trade.