How Does Odoo ERP Work?
Start with what ERP actually means
ERP stands for Enterprise Resource Planning. The name is unhelpful, so ignore it.
Here is what it really means. An ERP is a system where every part of your business writes to the same record book. Sales, stock, purchasing and accounting are not separate programs sending each other messages. They are different views of one set of data.
Odoo works this way. Once you understand that single idea, everything else about how it behaves makes sense.
The three layers
Odoo is built in three layers. You do not need to be technical to follow this, and it explains a lot about why the system behaves as it does.
The database. At the bottom sits PostgreSQL, a standard open-source database. Every customer, product, order, stock move and journal entry lives here. There is one database per company, and every app reads and writes to it.
The application server. In the middle sits the business logic — the rules. What happens when you confirm a sales order. How a price is calculated. Which approval is needed before a purchase goes out. This layer is written in Python, and it is the part that developers extend when a business needs something unusual.
The interface. On top sits what you see in the browser. Forms, lists, dashboards, reports. It also works on mobile, and it talks to the server, never directly to the database.
The important consequence: the rules live in one place. If you change how a discount is calculated, it changes everywhere — on screen, in reports, in the API, on mobile. There is no second copy of the rule to keep in sync.
FIGURE 1: THE THREE LAYERS OF AN ODOO SYSTEM
Interface
- What you see in the browser or on mobile. Forms, lists, dashboards, reports.
Application server
- The business rules. What happens on confirm, how a price is calculated.
PostgreSQL database
- Every customer, product, order, stock move and journal entry.
Apps are modules
Odoo is not one big program. It is a collection of modules, and each app you install is one of them.
Installing an app does three things. It adds new tables to the database, it adds new rules to the server, and it adds new menus and screens to the interface.
Because they all share one database, a newly installed app immediately understands what is already there. Switch on Manufacturing after two years of using Sales and Inventory, and it already knows your products, your units of measure and your stock locations. Nothing is migrated. It simply reads what exists.
This is also why custom modules work the same way. A developer building something specific to your business is doing exactly what Odoo’s own apps do — adding fields, rules and screens through the same framework.
Following one order through the system
The clearest way to understand Odoo is to follow a single transaction end to end.
Step 1 — The quotation. A salesperson creates a quotation for a customer. Odoo pulls the customer’s price list, payment terms and delivery address automatically, because that customer already exists in the database.
Step 2 — Confirmation. The customer accepts. The salesperson clicks Confirm. The quotation becomes a sales order, and Odoo immediately creates a delivery order for the warehouse.
Step 3 — The warehouse. The picking appears in the warehouse team’s list. They pick the goods and click Validate. At that moment Odoo records the stock move — the goods leave your warehouse location and go to the customer location. Stock on hand drops. If your products are set to real-time valuation, a journal entry is posted at the same instant, moving the value out of the stock account and into cost of goods sold.
Step 4 — The invoice. Back on the sales order, a Create Invoice button now shows. The invoice is drafted from the delivered quantities, not typed fresh. Accounts reviews it and posts it. Another journal entry hits the customer receivable and the sales income account.
Step 5 — Payment. The customer pays. The payment is registered and matched against the invoice. The receivable clears.
Count the manual data entries in that chain. One quotation, one validation, one invoice check, one payment. Everything else was a consequence.
Now count them in a disconnected setup: order in the CRM, picking note in a spreadsheet, invoice in the accounting package, stock adjustment somewhere else, and a reconciliation at month end to find out why the numbers disagree.
FIGURE 2: ONE ORDER FROM QUOTATION TO CASH
Quotation
- Prices pulled in
Sales Order
- Stock reserved
Delivery
- Stock and cost move
Invoice
- Drafted, then posted
Payment
- Receivable clears
How the parts talk to each other
Three mechanisms do most of the work behind the scenes. Knowing their names helps when you are configuring the system.
Automatic document creation. Confirming a sales order creates the delivery. Confirming a purchase order creates the receipt. Odoo calls these links, and they carry the quantity, product and partner across without retyping.
Stock valuation. When goods move, their value moves. If valuation is set to automatic, Odoo posts the accounting entry at the same moment as the stock move. Your inventory value on the balance sheet always matches the stock on hand.
Automated actions. You can set rules that fire on their own: send a reminder when an invoice is 30 days overdue, flag an order above a certain value for approval, notify a manager when stock falls below a minimum. These are configured in the interface, not coded.
Where reports come from
Because sales, stock and accounting share one database, reporting is a query, not a reconciliation.
When you open a margin report, Odoo is reading the same sales order lines and the same stock valuation layers that the operational screens use. There is no overnight export, no data warehouse and no second version of the truth.
This is why the numbers can be trusted in a well-set-up Odoo. It is also why a badly set-up Odoo produces confident wrong answers — the report is only as good as the configuration underneath it.
What this means for you
Three practical takeaways.
Configuration matters more than features. Almost every Odoo problem traces back to a setup decision — the wrong valuation method, an unclear warehouse structure, a chart of accounts that does not match how the business thinks. Get these right at the start.
Data quality is everything. One database means one bad record affects every app. A product with the wrong unit of measure will produce wrong stock, wrong costs and wrong margins, everywhere.
Understand your own process first. Before anyone configures anything, write down how an order actually moves through your business today, including the exceptions. That document is worth more than any feature comparison.
Planning an Odoo implementation?
Get in touch. We map your current process end to end before touching the system, because almost every Odoo problem traces back to a setup decision made too early.