Introduction
Different departments can use the same word to mean different things. Sales may call a confirmed quotation a sale. Operations may count it only after delivery. Finance may include it in a revenue measure only when invoiced or recognised under its accounting policy.
An Odoo KPI dictionary is the agreement that prevents this confusion. It records what each metric means, why it exists, how it is calculated, where the data comes from, who owns it, when it is refreshed, which records are excluded, what target applies and how a reader should interpret the result. It turns reports from collections of numbers into governed business information.
The dictionary is not a large technical catalogue. It is a practical bridge between business decisions and the Odoo data model. It helps finance, sales, purchasing, inventory, service and leadership teams use consistent language even when data passes through integrations or reporting tools. This guide explains how to design it without code and keep it useful after the first dashboard is published.
Business Requirement
The requirement is not simply more dashboards. People making decisions must use the same definition for the same measure. Without this foundation, reports can disagree even when they draw from Odoo. One team may include cancelled records while another excludes them. One may use invoice date while another uses delivery date.
Managers then spend time asking whose report is correct instead of asking what action is needed. Finance must reconcile executive KPIs to accounting figures. When a number changes, no one knows whether the business or the calculation changed.
An Odoo KPI dictionary establishes one approved definition for each decision-useful measure. It does not require every department to use the same metric. Sales needs pipeline conversion and activity coverage. Inventory needs availability and discrepancy indicators. Finance needs collection, close and reconciliation measures. The dictionary ensures that shared measures such as revenue, margin, backlog and active customers are comparable where needed.
Start With Decisions, Not Available Fields
Odoo offers data across sales, accounting, inventory, purchasing and projects. Starting with available fields encourages metrics that are easy to calculate rather than useful for a decision.
Ask what decision the KPI supports, who makes it and what action should follow outside the agreed range. An aged receivables KPI, for example, supports collection prioritisation and credit-risk action. Start with critical decisions such as cash collection, pipeline quality, fulfilment performance, inventory accuracy and period close.
Recognise That One Label Can Need Several Measures
Some labels are too broad to serve as a KPI by themselves. “Revenue” may mean quoted value, committed value, delivered value, invoiced value, recognised revenue or cash collected. These are not interchangeable. The dictionary should use distinct names such as “Invoiced Revenue By Invoice Date” or “Delivered Sales Value By Delivery Completion Date.”
Clear naming is a governance control. Avoid vague labels such as “Sales This Month” when the date basis and record state are unknown. The title should reveal the business event and time basis.
Architecture Choices
The dictionary needs an information architecture that separates definition from presentation. A chart, spreadsheet or dashboard is a consumer of the KPI. The dictionary is the governed specification. Store it where business owners and reporting teams can access the current approved version and where changes are controlled.
For many organisations, a managed document or table is a good first home. Each metric has one row or page with its definition and approval status. Mature environments may connect the dictionary to a data catalogue or reporting platform. The location matters less than ownership, version control and regular use during report design and review.
The Odoo system remains a source of operational records. A reporting layer or data warehouse may combine Odoo data with eCommerce, payment, manufacturing or CRM data. The dictionary must state the source of truth for every input.
| Dictionary Field | What It Defines | Example |
|---|---|---|
| KPI Name | Clear business label with event and date basis | Invoice Collection Days At Month-End |
| Purpose | Decision the measure is meant to support | Identify collection pressure and credit action |
| Formula | Numerator, denominator, logic and unit | Open receivables divided by average daily invoiced credit sales |
| Source | Odoo model, report or governed external source | Accounting entries and approved credit-sales population |
| Owner | Person accountable for definition and action | Credit control manager |
| Frequency | Refresh and review schedule | Daily refresh with weekly management review |
| Exclusions | Records intentionally left out and why | Intercompany balances excluded from commercial collection view |
| Target | Desired level or acceptable range | Below the agreed customer-segment threshold |
| Interpretation | Meaning, limits and expected action | Rising value requires ageing review before changing credit policy |
Choose The Right Source Layer
An Odoo KPI can be calculated directly in a native report, from an approved export or in a reporting platform. Use the simplest source layer that provides the required accuracy, access control and refresh speed. Do not extract data into a separate tool merely because it appears more flexible.
Native Odoo reporting may suit operational teams that need real-time drill-down. A governed spreadsheet can support limited analysis when its data source, logic and owner are clear. A BI platform or data warehouse may suit KPIs that combine systems, need historical snapshots or serve many users.
Record the chosen layer and its limitations. A live Odoo report may change when a backdated record is corrected. A nightly warehouse refresh may be one day behind. A manual adjustment should be labelled as such.
Define Time, Company And Currency Context
Most KPI conflicts arise from context. Record the reporting timezone, date field, date range, company scope, currency treatment and consolidation rules. An order measure based on confirmation date will differ from one based on delivery completion. A group revenue KPI may use a reporting currency while local teams use company currency. Neither is wrong when stated clearly.
Multi-company reporting needs additional discipline. Define whether the KPI includes all companies, selected legal entities or one operating unit. State how intercompany transactions are treated and who approves mapping changes. Note any acquisition, fiscal-calendar change or migration that breaks historical comparison.
Controls And Failure Modes
The dictionary needs controls because a good formula can still produce a misleading result. Records may be incomplete, integrations may fail, access rules may restrict the population or a user may change a dashboard calculation without updating the definition.
The most important control is a named owner. The owner is accountable for the business definition, not necessarily for technical extraction. The dictionary should show both responsibilities when they differ.
| Failure Mode | Reporting Risk | Preventive Or Detective Control |
|---|---|---|
| Unclear Status Logic | Draft, cancelled or duplicated records distort the population | Define valid states and reconcile counts to a known process report |
| Missing Master Data | Customer, product or company gaps prevent segmentation | Track completeness rules and assign data owners |
| Integration Delay | External transactions arrive late or twice | Monitor freshness, error queue and reconciliation totals |
| Uncontrolled Formula Change | Dashboard result changes without explanation | Version the definition and require owner approval for material changes |
| Access Difference | Users see different populations because of record rules | Test each report by role and document the intended scope |
| Manual Adjustment | Board number cannot be traced to source data | Label adjustment, reason, owner and approval evidence |
Make Exclusions Explicit
Exclusions are not a weakness. They make a KPI trustworthy when they are justified and visible. A service-level metric may exclude customer-caused delays. A margin KPI may exclude intercompany transactions when it is designed for external commercial performance. A sales conversion metric may exclude test leads or records created through a migration.
Every exclusion needs a rule. State the record condition, reason, expected volume and owner who may approve a change. Do not use an informal exclusion that lives only in an analyst’s report filter. If the exclusion becomes material, show both the included result and the excluded volume so leaders can assess the impact.
Protect Interpretation From Misuse
A KPI is not a verdict. It is a signal that must be read with operating context. A lower inventory value may improve working capital but create stockout risk. A faster close may be positive but not if key reconciliations were deferred. A high activity count may not mean stronger selling if lead quality has declined.
The interpretation field should say what the KPI can indicate, what it cannot prove and which companion metric should be checked. For example, first-response time should be read with ticket resolution quality and reopen rate. Invoice collection days should be read with overdue balance, dispute ageing and write-off trend. This simple instruction prevents management from optimising one number at the expense of the process.
Testing
Test a KPI as a business artefact, not only as a calculation. Begin with a small set of transactions whose expected result is known. Include normal cases, cancellations, returns, credit notes, partial deliveries, intercompany records and late adjustments where relevant. Confirm that the KPI handles each case according to its stated definition.
Next, reconcile the metric to a control total. A sales KPI may reconcile to an approved sales population. A receivables KPI may reconcile to the relevant accounting balance after its exclusions. A delivery KPI may reconcile to completed transfers. Record the reconciliation method and acceptable difference in the dictionary or its related control note.
Test the result by role as well. Reporting access should not reveal records a user is not permitted to see. At the same time, a manager should not receive an incomplete KPI without understanding that their record rules limit the result. Role-based testing is essential when company scope, team ownership or sensitive financial data is involved.
Test Changes Before Publishing
Treat a material KPI change like a controlled reporting release. A change may be a new formula, an altered source, a new company, revised status mapping or updated target. The change request should state the reason, impact on historical trends, test evidence, approval and effective date.
Where possible, run old and new definitions in parallel for a short period. Explain the difference to report users before replacing a familiar number. If restating history is necessary, label the restated period and preserve the former definition for auditability. Silent changes damage trust even when the new measure is better.
Governance Checklist
Use a regular governance review to keep the dictionary alive. Monthly may suit executive and finance KPIs while weekly may suit operational measures. Review new requests, definition changes, data-quality issues, source freshness, exceptions, targets and unused metrics. The objective is to make reporting decisions easier, not to create another committee.
The review should ask whether each KPI still supports a real decision. Remove duplicates and retire measures with no owner or no action. Confirm that targets remain appropriate as the business changes. Revisit the dictionary after an Odoo implementation phase, major integration, migration, acquisition or reporting-platform change.
The checklist below gives a concise starting point:
- Give every KPI a business name that states the event and time basis.
- Record its purpose, exact formula, unit, source, owner and refresh frequency.
- Define company scope, date field, currency treatment and historical-comparison limits.
- Document exclusions, data-quality rules, control total and interpretation guidance.
- Test normal and exceptional transactions against the approved definition.
- Check access by user role and disclose any intentionally limited population.
- Approve material changes, retain version history and communicate trend breaks.
- Review targets, exceptions and unused metrics on a defined schedule.
For organisations connecting several systems, Odoo integration services and ERP data migration services can help align source ownership, data quality and reporting reconciliation. The critical outcome is not a larger dashboard. It is an agreed KPI definition that remains dependable as Odoo workflows, integrations and reporting needs evolve.
Conclusion
An Odoo KPI dictionary gives every department a shared foundation for reporting. It replaces ambiguous labels and hidden filters with a clear agreement about the business purpose, calculation, source, owner, exclusions, target and interpretation of each metric. That agreement helps leaders spend less time challenging numbers and more time acting on them.
Start with the few KPIs that guide important decisions across departments. Define their context as carefully as their formula, test them against real transactions and make changes visible. A concise, owned and regularly reviewed dictionary makes Odoo reporting more consistent whether a KPI appears in a native report, spreadsheet or enterprise BI platform.
Frequently Asked Questions
1. What Is An Odoo KPI Dictionary?
An Odoo KPI dictionary is a governed reference for business metrics used in Odoo reporting. It records each KPI’s name, purpose, formula, source, owner, frequency, exclusions, target and interpretation so departments use the same definition.
2. Why Do Departments Need A Shared KPI Definition?
Departments often use different date fields, document states, company scopes or exclusions. A shared definition prevents conflicting reports and makes it clear which measure should support a particular business decision.
3. What Should Every KPI Entry Include?
Include the KPI name, purpose, formula, source, owner, refresh frequency, scope, exclusions, target, interpretation, data-quality checks and approval status. Add a version history when the measure changes materially.
4. Can An Odoo KPI Use Data From Other Systems?
Yes. The dictionary should explicitly state every source, the integration or extraction method, refresh timing, reconciliation control and owner. A combined KPI is dependable only when its inputs and limitations are visible.
5. How Should We Handle KPI Exclusions?
Document the exact records excluded, the reason, expected volume and owner who can approve a change. Show the excluded volume when it could materially affect how leaders interpret the result.
6. How Often Should A KPI Dictionary Be Reviewed?
Review it on a schedule that fits the KPI and whenever a material change occurs. Finance and executive measures may need monthly review while operational measures may need weekly review. Review again after an implementation phase, integration or migration.
7. Who Owns An Odoo KPI Dictionary?
Business owners should own the meaning and intended use of KPIs. Reporting or data teams can maintain the technical logic, while integration and system owners support source reliability. The dictionary should name these responsibilities clearly.
