Sales managers already running Odoo tend to ask the same question when annual planning season arrives: how detailed can a sales target be? Setting a total target per salesperson is clearly supported. But what about stating which customer should buy which product, for how much, in which month? Does the standard system handle that?
This article answers that from Odoo's official documentation and from a survey of modules other developers have already published. It then explains what the missing part requires, using the Sales Plan module our company built as the worked example.
First, the terms used throughout. Odoo is an enterprise resource planning system, or ERP, which keeps sales, accounting, and inventory work on a single set of records. A module is an extension that adds capability to that system without replacing the whole thing.
How far the standard system goes
In the standard system, an administrator can set a revenue target for each salesperson and for each sales team. The official documentation describes this value as the revenue target for the current month, which is enough for tracking monthly performance at an aggregate level.
Another tool often mistaken for target setting is the Forecast report in the customer relationship work. That report estimates revenue from the opportunities recorded in the system, multiplying each opportunity's expected revenue by its probability and grouping the result by expected closing month. It answers how much the current pipeline is worth. It does not answer whether the organization is meeting the targets it set.
Extending the survey to the Odoo Apps Store, where developers worldwide publish their modules, our review in June 2026 found five modules addressing sales targets. All of them set targets at salesperson and team level, some break the figures down by product group, and one produces sales forecasts by statistical methods. But none combined customer level, product level, and time period within a single target. That survey did not cover every developer, so the honest conclusion is that we did not find one, not that none exists.
Who actually needs customer and product level detail
Not every business needs this level of detail. A business selling high volumes to ordinary consumers is well served by targets at salesperson level. But a business that sells repeatedly to the same corporate accounts, with a few dozen key customers and a regular set of products each of them orders in cycles, will find that a salesperson's total hides what ought to be visible.
Consider a hypothetical distributor of industrial raw materials. One salesperson hits the total target for the whole quarter, but inside that total three major accounts have cut their orders of the main product, and orders from new customers happen to cover the difference exactly. The combined figure shows no signal at all, even though the existing customer base is shrinking. A problem like that becomes visible when targets are set at customer and product level from the start, and actual results are compared at the same level.
Many organizations solve this with a spreadsheet of their own making, which does answer the need for detail, but at the cost of three limitations: comparing against actual sales requires manual entry every month, salespeople cannot be restricted to seeing only their own figures, and there is no record of when a target was changed or by whom.
How many sets of data a target comparison needs
A target becomes useful when it can be compared with real results without re-entering anything. Those results already exist in Odoo's sales and accounting records. The question is which documents to count from. In designing the module, we separated them into the three sets in the table below.
| Data | Counted from | Assigned to the month of |
|---|---|---|
| Actual sales | Posted invoices | The invoice date |
| Cash received | Paid invoices, split by payment instalment | The payment date |
| Confirmed orders not yet invoiced | Confirmed sales orders with no invoice issued yet | The delivery commitment date |
The three are kept apart because each answers a different question. Actual sales measure performance against target. Cash received shows the incoming cash flow, which typically trails the sale by several weeks. Confirmed orders not yet invoiced show work already secured but not yet turned into revenue. Merging all three into one figure would make performance look better than it is.
One point we paid particular attention to is sales that were never in the plan. If a customer buys a product for which nobody set a target, that line appears in the report on its own, labelled as an unplanned sale. This works because the report does not start from the target rows alone, but also pulls in every actual sale recorded in that period.
Targets from management and targets from the sales team
The problem that surfaced during requirements gathering was not detail alone. It was that targets arrive from two directions at once. Management sets the aggregate figure, such as what a product category should deliver in a given territory, while each salesperson plans targets for their own accounts by product and by month. The two sets rarely match.
The module therefore keeps the two levels separately, then rolls up the detailed targets that fall within each group and displays them next to the aggregate figure. The result is that the gap between what management set and what the team actually planned is visible before the plan is approved, rather than half a year later.
The reports for the two levels are entirely separate, and no amounts are added across levels. That is a deliberate design decision, because combining an aggregate target with the detailed targets underneath it double counts immediately.
What this module does not do
Describing only the working parts would leave an incomplete picture. The following are deliberately outside its scope.
- It does not calculate sales commission, because compensation rules differ far too much between organizations
- It does not forecast sales automatically. Someone still has to set the target, and the system only helps by building next year's targets from the previous year's figures with a growth rate applied
- Approval is a single step by the team manager, and can be switched on or off. Multi-step approval is not part of this round
- Data import and export use Odoo's standard functions rather than purpose-built tools
The first three are scope choices made so that the core could be finished first. The last one is a decision not to rebuild something the platform already provides.
In summary
Standard Odoo sets targets at salesperson and team level, which is sufficient for aggregate tracking. Targets at customer and product level, compared automatically against real results, are the part that has to be built, and they bring decisions that must be made up front about which documents count as actual sales and how to avoid double counting.
For more on the ERP work we do, see the ERP Odoo page, or contact our team to discuss whether this approach fits the sales process in your organization