Odoo Community's Purchase Module: No More Purchase Orders by Email

In this article

• What the Purchase module actually does: from the request for quotation to the confirmed purchase order, with suppliers, their prices and lead times in one place.
• The integration that changes everything: a confirmed order creates the receipt, and the vendor bill is prepared from the order.
• Three settings to get right before you use it: the bill control policy, the purchase agreements to switch on, and the approval threshold.
• Three-way matching needs Enterprise, and here is what replaces it: account_3way_match is not in the Community repository, but the control policy and the line matching screen cover most of the need.
• Before and after: the comparison that speaks for itself: seven processes, from the purchase order to reporting, set side by side with the manual method.
• Community vs Enterprise: what are you missing?: the supplier portal is already in Community; Studio, the mobile app and automated matching stay Enterprise.
• The questions you will be able to answer a year from now: days to confirm, days to receive, average cost and four quantities per line, with nothing added.
• What's missing (and what we can add): one approval level, no purchase budgets, no punchout, and configuration that deserves real time.
• How we deploy it: Odoo Community hosted in Quebec, Law 25 compliant, and we build on top rather than migrating you.

In a lot of SMBs, purchasing still looks like a mix of emails, Excel files, and Word purchase orders sent as attachments. The supplier replies "looks good," you order, the delivery shows up three weeks later, and when it's time to match the invoice with what was ordered and received: good luck.

The worst part is that it works. Until the day it doesn't. A supplier invoices a different price than what was agreed. An order falls through the cracks because nobody knew someone else had already placed it. Or simply: you have zero visibility on how much you're spending, with whom, and how fast.

Odoo Community's Purchase module is built for exactly this. Not a complex procurement system for a multinational: a structured tool to make your purchases traceable, approvable, and integrated with the rest of your operations.

What the Purchase module actually does

At the heart of the module is the purchase order. You create a Request for Quotation (RFQ), send it to the supplier by email directly from Odoo, and when it's confirmed, it becomes an official purchase order. Every step is tracked: who requested what, when, at what price, and where things stand.

But the module doesn't stop there. Here are the main features:

Supplier management: each product can have multiple suppliers with their prices, lead times, and minimum quantities. When you create a purchase order, Odoo can automatically suggest the best supplier based on your rules.

Requests for Quotation (RFQ): you can send quote requests to multiple suppliers at the same time, compare offers, and pick the best one. All in a centralized interface instead of juggling emails.

Purchase agreements: two types exist. Blanket orders let you negotiate a price with a supplier for a set period, then place partial orders as needed. Purchase templates cover the quote requests that come back regularly: the product list is kept as is and reused, with one supplier or another. A call for tenders is not an agreement type in Odoo 19: you run one by creating alternative requests for quotation for several suppliers, then comparing them side by side.

Approvals: you can set an approval threshold so that purchase orders above a certain amount require manager validation before being confirmed. It's a simple but effective level of control.

Vendor bill control: every product carries a policy saying whether the vendor can bill on ordered quantities or only on the quantities actually received. That is the basic guard rail against a bill that does not match the delivery, and we come back to it below, with what needs Enterprise and what does not.

The integration that changes everything

What makes the Purchase module really interesting is that it doesn't live in isolation. It integrates directly with two other key modules:

Inventory: when a purchase order is confirmed, Odoo automatically creates a receipt transfer. When products arrive, you validate the receipt and your inventory updates itself. No more entering the same information twice.

Accounting: when you receive a vendor bill, Odoo can create it directly from the purchase order. Journal entries are generated automatically. The bill control we talked about earlier is exactly this integration in action: Odoo knows what was ordered, what was received and what is being billed, because all three live in the same database.

The result: a complete chain from "I need to order something" to "it's paid and recorded," with no manual re-entry and full traceability.

Three settings to get right before you use it

The module installs in two clicks, and that is where a lot of deployments stop. Three settings decide what the tool will actually spare you.

The bill control policy, product by product. This is the most important setting and the least known. Every product carries a policy saying what the vendor may bill you for: the quantities ordered, or the quantities received. Set to received quantities, Odoo will not prepare a bill for what has not arrived. The default depends on the type: a service goes on ordered quantities, goods on received quantities. If you take one setting away from this article, take that one.

Purchase agreements, to be switched on. Blanket orders and purchase templates are not visible out of the box: they come from a companion module, Purchase Agreements, that you tick in the Purchase settings. It is very much in Community, but until the box is ticked the menu does not exist, and people conclude a little too quickly that Odoo cannot do it. A second checkbox appears right below it, Purchase Alternatives, and that is the one that links requests for quotation together so you can compare them: the call for tenders lives there, not in the agreements menu.

The approval threshold. Same logic: you turn on double validation in the settings, set the amount, and purchase orders above it go through a manager. One level only, but it takes a minute to configure.

Three-way matching needs Enterprise, and here is what replaces it

Odoo's automated three-way matching, the one that adds a "Should Be Paid" field on the vendor bill, is not in Community. The point is often reported wrong, so it is worth being precise. It comes from a separate module, account_3way_match, which is not part of the Community repository: in Community's Purchase settings the checkbox exists but is displayed with the upgrade-to-Enterprise button.

What Community gives you instead is not nothing, and it covers most of the need.

The control policy described above is already the main guard rail: set to received quantities, a bill for goods that never arrived does not get prepared. And a line matching screen lines up purchase order lines against bill lines, one by one, with quantities already invoiced, quantities left to invoice, and the amounts on both sides. You see the gap, and you correct the price or the quantity right there.

So the difference comes down to one word: in Community the gap is noticed by you, in Enterprise it is flagged for you. And even then, Odoo's documentation is honest about it: when a draft bill is edited the field switches to exception, but Odoo "does not block the changes or display an error message", since there might be a valid reason for the change. Neither edition excuses you from looking.

Before and after: the comparison that speaks for itself

Community vs Enterprise: what are you missing?

The Purchase module is very complete in the Community edition. Here's what's included, and what requires Enterprise:

In practice, for most SMBs, the Community edition covers the need very well. The supplier portal, often presented as an Enterprise addition, is already in Community: the Purchase module serves the /my/rfq and /my/purchase routes, where the supplier reads their requests for quotation and orders, prints the PDF, sees the related bills and corrects the expected delivery dates. What it does not do: take in a bill the supplier would upload themselves.

The questions you will be able to answer a year from now

This is the argument nobody makes, because it does not show up in the first week. Structuring your purchasing is not only about placing an order properly: it builds a history, and the history answers questions a folder of emails never will.

Community's purchase analysis report, with nothing added, measures among other things the days to confirm and the days to receive, the average cost per product, and four distinct quantities on every line: ordered, received, billed, and left to be billed.

Put together, that gives concrete answers. Which vendor actually delivers within the promised lead time, and which one has slipped over the past six months. What you paid for the same product across three different vendors last year. Which orders have been received but still not billed, which is precisely the list of unpleasant surprises waiting at your year end.

None of those questions needs Enterprise. They only need the orders to be placed in the system rather than in an attachment, and that is the whole point of this article.

What's missing (and what we can add)

Like any Odoo module, there are limitations worth knowing:

Multi-level approvals: the standard module offers a single approval level based on amount. If you need complex approval chains (amount X = manager, amount Y = director, amount Z = VP), you'll need a complementary module from the OCA or custom development.

Purchase budget management: Odoo Community doesn't natively manage purchase budgets by department or category: no budget module ships in the Community 19.0 branch. You'll see how much you've spent, but there's no automatic alert when you're approaching a budget ceiling.

Punchout and supplier catalogs: if you work with large distributors that offer integrated online catalogs (punchout), it's not native in Odoo. It exists through third-party modules, but it's an add-on.

Learning curve: the module is intuitive for basic operations, but purchase agreements and bill control policies require some configuration and training to be used properly.

How we deploy it

At Blue Fox, we deploy the Purchase module in Community edition because it's open source, we have full control over the code and data, and for the vast majority of SMBs and non-profits we work with, it's more than enough.

We host instances in Quebec, on sovereign infrastructure, with Law 25 compliance built in from the start. And if someday you need to go further (multi-level approvals, specific integrations), we build on top rather than migrating you to another system.

Sources

• Odoo 19 documentation, Purchase module: the official reference.
• Odoo 19 documentation, control policies: ordered or received quantities, the default per product type, and the admission that Odoo flags the discrepancy without blocking it.
• Odoo 19 documentation, blanket orders: the first of the two agreement types, and how it is switched on.
• Odoo 19 documentation, purchase templates: the second agreement type, for the quote requests that come back regularly.
• Odoo 19 documentation, call for tenders: why it runs through alternative requests for quotation rather than through an agreement.
• Odoo, editions comparison: what separates Community from Enterprise, including Studio and the mobile apps.
• The Odoo Community repository, branch 19.0: the list of modules actually shipped in Community. purchase and purchase_requisition are there, account_3way_match is not.
• The supplier portal controller, inside Community's Purchase module: the /my/rfq and /my/purchase routes, shipped in Community.
• Odoo, Purchase features page: the commercial overview of the module.