Overview
“Implement sales, inventory and accounting” sounds like a clear project brief until configuration starts. One manager expects two companies. Another assumes every warehouse is included. Finance wants historical comparisons while the migration estimate covers only opening balances.
An Odoo scope baseline prevents these different expectations from becoming delivery disputes. It records the approved boundaries of the implementation, the responsibilities attached to them and the evidence needed to accept the work.
The first release needs enough definition to estimate, configure and test while leaving room for detailed design.
This guide explains what to include, how to resolve uncertain requirements and how the baseline fits into a wider Odoo implementation services engagement.
What Is an Odoo Scope Baseline?
An Odoo scope baseline is the approved reference for what a defined delivery phase includes and excludes. It connects business processes to companies, locations, users, reports, integrations, migration boundaries and acceptance criteria.
Record the baseline version, approval date and approvers alongside the target Odoo version, edition and hosting arrangement. Link detailed registers through stable requirement identifiers.
The baseline defines the required outcome and delivery boundary. Solution design explains how Odoo will meet them. The project plan schedules the work. The contract establishes commercial responsibilities. These documents should agree without duplicating every detail.
A baseline also allows controlled change. It gives the team a reliable starting point for assessing whether a new request changes cost, timing, responsibilities or expected outcomes.
Start With Business Process Discovery
Begin business process discovery with the people who perform and own the work. Ask them to show recent transactions, forms, spreadsheets and exception cases. A department’s description of its process may differ from what employees actually do.
For each process, capture the trigger, starting record, major decisions, handoffs and completion point. Identify transaction volumes, busy periods and problems worth solving. Include current controls and the consequences of bypassing them.
Distinguish the approved future process from current habits. A spreadsheet may represent a genuine reporting requirement or simply compensate for inconsistent data entry. That difference affects scope and design.
Assign a process owner who can settle conflicting requirements. The consultant documents options and dependencies while the business decides which operating rules the implementation must support.
Build a Scope Register Across Nine Dimensions
Use a single register or linked worksheets to capture the dimensions below. Replace broad labels such as “all users” and “full migration” with named populations, counts, periods and conditions.
| Scope Dimension | What to Define | Evidence to Attach |
|---|---|---|
| Processes | Start and end points, variants, approvals and exceptions | Approved process map and representative transactions |
| Companies | Named entities, currencies, accounting boundaries and shared operations | Entity register and finance requirements |
| Locations | Warehouses, internal locations, branches and stock movements | Site list and movement scenarios |
| Users | Role counts, access boundaries, approvers and external users | Role matrix and access test cases |
| Reports | Decisions supported, formulas, filters, frequency and recipients | Report catalogue and expected sample totals |
| Integrations | Systems, records, direction, timing and failure ownership | Interface register and recovery scenarios |
| Data history | Objects, date ranges, opening positions and archive access | Migration inventory and reconciliation rules |
| Exclusions | Deferred or omitted requirements and temporary arrangements | Exclusion register with business owners |
| Acceptance | Observable results, test conditions, tolerances and approvers | Requirement-linked acceptance scenarios |
Give each entry an identifier such as PROC-01 or INT-02. Record its release, business owner, priority, assumptions and status. A requirement marked “to be confirmed” needs a decision owner and deadline before dependent work begins.
Define Processes Through Transactions and Exceptions
“Order-to-cash” is a useful heading but an incomplete requirement. Define whether the release includes quotations, discounts, credit checks, partial deliveries, returns, invoicing, collection and reconciliation. Specify where another system or a manual process remains responsible.
For each variation, ask whether it is essential at launch. Low volume does not automatically mean low importance: an occasional refund or disputed payment may require a reliable control from the first day.
Consider an illustrative distributor moving from emailed orders and spreadsheet stock checks to a connected Odoo workflow. Its first phase covers one company and one warehouse. Online marketplace orders remain outside this phase.
| Transaction Stage | Proposed Movement Through Odoo | Baseline Decision and Acceptance Evidence |
|---|---|---|
| Sales order | Approved customer, product and price information becomes a confirmed order | Sales owner verifies agreed pricing and approval conditions |
| Delivery | Order demand leads to picking and delivery records | Warehouse owner tests full delivery, shortage and backorder handling |
| Invoice | Delivered quantities become eligible for invoicing under the selected policy | Finance verifies that the agreed quantities and charges appear correctly |
| Payment | Recorded receipts are matched with the relevant accounting entries | Finance tests full payment, partial payment and unmatched receipts |
| Return | Returned goods and any credit follow the agreed operational and financial process | Warehouse and finance verify quantities, approval and linked records |
This is an illustrative target design, not a client result or a promise of default behaviour. Confirm each step in the selected version and configuration. The baseline must state the intended behaviour even when detailed configuration is still pending.
Separate Companies From Physical Locations
List each legal entity in the first release and identify which transactions it owns. Capture currencies, accounting requirements, document ownership and cross-company activity. Finance should validate local requirements before the team approves the structure.
Then list physical sites and their operational roles. Distinguish warehouses from internal storage locations and clarify how branches should be represented. A postal address alone does not determine the correct Odoo structure.
Define transfers, shared stock expectations and reporting boundaries. Ask whether users need visibility across sites and whether they may act across companies. A second warehouse can introduce new routes, permissions and test cases even when the same applications are used.
Record future entities separately. Their anticipated needs can inform architecture without becoming an unpriced commitment in the current Odoo rollout.
Scope Users by Role and Authority
A user count supports commercial planning but does not define operational access. Group users by the work they perform and the authority they require. Include managers, administrators, temporary staff and external portal users where relevant.
For each role, identify the records it may view, create, change and approve. Odoo’s documentation describes access rights through users and groups, including permissions for reading, writing, creating and deleting records. Your baseline should translate these controls into business responsibilities.
Specify restrictions that must be demonstrated during testing. For example, a warehouse operator may need to complete authorised movements while remaining unable to change protected financial information. Avoid using administrator access as the basis for business acceptance.
Include role-based training, named super-users and the expected evidence of independent task completion. These are delivery requirements that support Odoo adoption.
Describe Reports as Business Decisions
Replace “management dashboard” with a report definition. Name the audience, decision supported, calculation, data source, filters and update frequency. Specify whether the requirement concerns an operational list, financial statement, printed document or consolidated view.
For a sales margin report, decide which costs it uses, whether it includes returns and how it treats companies and currencies. Attach sample data and expected totals so that the team can verify the calculation.
Label the proposed delivery approach as standard reporting, configuration, external analytics or custom development. Do not approve “all existing reports” without reviewing which ones remain necessary.
During solution design, confirm that required fields are captured by the underlying process. A report cannot reliably calculate information the implementation never records.
Bound Each Integration and Its Exceptions
Name every external system and the business records exchanged. Define direction, frequency, source ownership and the point at which an update becomes authoritative. “Connect the website” leaves too many decisions unresolved.
For example, order import and stock publication are separate interface requirements. Each needs field mapping, identifiers, validation rules and an owner. Clarify whether cancellations, refunds, attachments and historical records are included.
Scope failure handling alongside successful transfers. Require a process for detecting rejected messages, preventing duplicate transactions and replaying failed updates. Define who investigates mismatches and which team communicates with the external provider.
Record dependencies such as credentials, test environments, provider access and service limits. Verify compatibility with the selected Odoo version, hosting arrangement and subscription before committing the interface to delivery.
Decide How Much Data History to Bring
Separate master data, opening positions, open transactions and closed history. Each category has a different operational purpose and validation burden. “Three years of history” must identify the objects, dates, attachments and relationships involved.
Compare migrating detailed transactions with retaining older information in a searchable archive or reporting environment. Finance and operational owners should decide what must remain available inside Odoo and what can be accessed elsewhere.
Odoo documents External IDs as a way to preserve relationships and update imported records. Changing or removing these identifiers can create duplicates during subsequent imports. Include identifier mapping and repeat-import behaviour in migration scope.
Define who cleans the source data, the cut-off date, trial loads and reconciliation evidence. Explain how opening balances and imported open items avoid double counting. For archives, name the access owner and retrieval process. Historical availability is incomplete if users cannot find the records they need.
Record Exclusions, Assumptions and Dependencies
An exclusion should explain the boundary and its operational consequence. “Payroll excluded” is clearer when it also identifies the retained payroll system and how approved accounting information will reach Odoo.
Separate deferred work from permanently omitted requirements. Attach a temporary process and owner to any deferred capability needed for daily operations. Review whether that arrangement creates extra manual effort or control gaps.
Assumptions should be testable. Replace “customer provides clean data” with named datasets, validation rules, owners and delivery dates. Record third-party availability and business participation in the same way.
Use roadmap planning to sequence later releases around dependencies. A deferred interface may still require fields or identifiers in the first release, so its future needs should be understood without including its full delivery.
Write Acceptance Criteria Before Configuration
Acceptance criteria describe what a reviewer must observe. They should specify starting conditions, user role, action, expected result and evidence. Add volumes, time limits or tolerances where performance or reconciliation requires them.
| Vague Requirement | Testable Acceptance Criterion | Approver |
|---|---|---|
| Support partial deliveries | With an order for 10 units and 6 delivered, the agreed delivered-quantity policy allows invoicing for 6 while the remaining quantity is handled as specified | Sales and finance owners |
| Import opening stock | Quantities reconcile to approved source totals by product and location; every difference is resolved or explicitly accepted | Inventory owner |
| Prevent duplicate orders | Replaying the same external order identifier creates no additional sales order and records the agreed outcome | Integration owner |
| Provide accurate reporting | The agreed dataset produces the approved totals with the specified company, date and status filters | Report owner |
These are proposed criteria to validate, not statements that every control is automatically available. Identify where configuration, an integration mechanism or an extension is needed.
Connect every mandatory requirement to a test and approver. Agree defect severity, release-blocking conditions and how accepted deviations are documented. Keep business benefit targets separate: lower processing time after adoption is different from proving that an agreed workflow functions correctly.
Approve the Baseline and Control Changes
Within the Odoo implementation methodology, baseline approval should follow discovery and sufficient fit validation. Short prototypes may resolve uncertainty before approval. Detailed configuration can then proceed against an agreed release boundary.
The sponsor approves business priorities and funding. Process owners approve operational requirements. Finance validates accounting and reconciliation needs. IT confirms dependencies and access requirements. The delivery lead confirms feasibility, estimates and responsibilities.
Use this final approval checklist:
All scope dimensions identify included populations and boundaries.
Mandatory processes include normal and exception scenarios.
Assumptions have owners and decision dates.
Acceptance criteria connect to requirements and approvers.
Training, cutover and support services have defined deliverables and owners.
The approved version matches the estimate and release plan.
After approval, log proposed changes against the affected requirement. Assess their impact on design, data, testing, training, cost and schedule. Distinguish a defect against agreed behaviour from a new requirement. Record the decision and publish the revised baseline when a change is approved.
This makes ERP governance usable in daily delivery while preserving a record of approved changes.
Frequently Asked Questions
1. Who should own the Odoo scope baseline?
The project manager should maintain the controlled document while business process owners approve their requirements. The executive sponsor resolves priority and funding conflicts. The implementation partner contributes feasibility analysis and estimates but should not independently decide the customer’s business boundaries.
2. Is a module list enough to define scope?
No. Applications identify broad capabilities but leave process variants, companies, locations, permissions, reports and migration expectations unresolved. A useful baseline explains how the business will operate within those applications and what evidence demonstrates that delivery is complete.
3. Can configuration begin with unresolved requirements?
Only where the approved work is sufficiently independent of those decisions. Record unresolved items with owners and deadlines. Pause dependent configuration when an unanswered question could change the structure or expected behaviour. Use a bounded prototype where it helps resolve uncertainty.
4. Does the baseline need every field and screen defined?
No. It needs enough detail to establish boundaries, estimate effort and define acceptance. Detailed field layouts and configuration choices can follow during solution design. Business-critical data, controls and outputs should already be explicit because they affect delivery obligations.
5. Should all historical data move into Odoo?
Not automatically. Identify which records support ongoing transactions, reporting and retrieval requirements. Compare detailed migration with an accessible archive. Approve date ranges and data objects separately, including how users will access excluded history and who validates the migrated information.
6. How does a scope baseline support Odoo adoption?
It makes user roles, training, exception handling and support responsibilities visible before delivery begins. Users can test representative work against agreed expectations. This reduces uncertainty about how the new process operates and who helps when tasks cannot be completed normally.
7. How should scope changes affect the project plan?
Assess each request before committing it to a release. A small change can affect data, integrations and testing beyond the visible screen. Update approved costs, dependencies and dates where necessary, then communicate the revised baseline to everyone responsible for delivery.
Conclusion
An Odoo scope baseline turns a broad implementation ambition into an agreed delivery commitment. Define processes, organisational boundaries, users, reports, interfaces and data history alongside exclusions and acceptance evidence.
Give unresolved decisions owners and control changes through a shared register. If these boundaries remain unclear, begin with discovery through Odoo implementation services and produce the baseline before authorising detailed configuration.
