In this piece
SAP Business One to Odoo: how much history should move?
“Take all the history” sounds safer than deciding what to leave behind. It still leaves a difficult question unanswered: should a paid invoice become an active accounting record, a reference for customer service, or a document someone can retrieve from an archive?
Move the records needed to continue approved work in Odoo, coordinate open items with one agreed opening position, and retain the remaining history through a tested retrieval route. Choose each dataset by the job it must support. A number of years is a filter, not a complete migration scope.
Research checked: 5 November 2026. The source boundaries below use official Odoo 20 documentation, SAP Business One’s public archive guide and a public SAP knowledge-base preview. The register and amounts are synthetic examples. We did not access a business database or execute a SAP-to-Odoo migration.
Which records need an operational future in Odoo?
Start with the first task someone must complete after the switch. Identify the records and relationships that task depends on, then define their permitted target effect. An active customer, an unfinished order and a settled invoice can share a source history while needing different destinations and different acceptance evidence.
| Purpose | Example | Permitted effect | Proof to request |
|---|---|---|---|
| Continue work | Active customer and remaining order lines | Support the approved next operational step. | A user can complete that step without repeating completed work. |
| Establish the opening position | Open invoices and approved opening balances | Represent the agreed financial position once. | Finance accepts the reconciliation and target treatment. |
| Consult selected history | A service record needed for an active serial number | Provide context without creating an unapproved movement or obligation. | The right user retrieves the linked evidence. |
| Retain older evidence | Closed invoices and their attachments | Allow authorized historical consultation. | A retrieval exercise returns the required original and context. |
Consider an open order with some lines already delivered. The scope needs the remaining work and enough context to explain it. Importing the original order total without deciding how completed lines are represented may give the user the wrong next action. The scope owner should approve the continuation behavior before an engineer designs the import.
Keep source identity available across these destinations. A proposed reference can include the source company, record type and source identifier. Do not assume a visible document number is unique across every company database. Decide where the mapping from source record to target record or archive location will be maintained.
Record the actual SAP Business One version and database platform, target Odoo version, installed apps and relevant custom fields. A procedure for another SAP product or a different Odoo configuration needs separate verification. This article does not establish a universal converter or a compatible connector release.
How do open items relate to the opening balance?
Open items explain the outstanding obligations, while the opening position states the financial starting point. Their target representations must work together. Ask finance to approve the treatment and reconciliation before loading either dataset, including how duplicates or changes after the cutoff will be detected. A successful import alone is insufficient evidence.
Odoo 20's opening-entry guidance warns that importing open documents and opening balances incorrectly can duplicate values.
Use this fictional control-total example. It describes the exposure that the scope must preserve; it does not prescribe journal entries, clearing accounts, tax handling or a posting sequence.
| Source item | Remaining exposure | Scope requirement |
|---|---|---|
| INV-A | EUR 15,000 | Preserve customer identity, source reference and the remaining amount. |
| INV-B | EUR 8,000 | Preserve the same evidence for this separate item. |
| Combined open items | EUR 23,000 | Reconcile to the finance-approved opening representation. |
| Duplicate representation to reject | EUR 23,000 + EUR 23,000 = EUR 46,000 | Do not accept the same exposure contributing twice. |
The two invoices may be needed for subsequent collection work. That does not authorize adding another independent EUR 23,000 contribution without the approved accounting treatment. Equally, an aggregate amount alone may leave the user unable to identify which customer document remains unpaid. Both the financial total and the intended user task need evidence.
SAP’s public opening-balance KBA preview also notes that existing postings do not by themselves prevent further opening balances; a locked posting period is a restriction. This is a SAP behavior boundary, not proof of an Odoo safeguard.
Keep the cutoff explicit. If INV-A changes after the approved extract, its earlier amount no longer proves the final scope. Record the correction and ask finance which evidence must be refreshed. Do not silently alter a spreadsheet while keeping the previous approval attached.
Which closed history earns a place in Odoo?
Bring closed history into Odoo when a named workflow needs it there and the target representation can satisfy that need without an unintended business effect. Require an owner to describe the retrieval or reporting job. Keep the scope selective, and test the behavior of the chosen representation before extending the period.
A support team may need a service intervention linked to an active serial number. A sales team may need to consult an old agreement before renewing it. These examples justify questions about specific fields and relationships. They do not automatically justify recreating every underlying financial transaction.
Specify whether the history will be an attachment, a dedicated reference record, a reporting dataset or a link to an external archive. Those are design alternatives to evaluate, not interchangeable native import capabilities promised by this guide. Each has different consequences for search, permissions and maintenance.
For a paid invoice, a useful acceptance question is: can the authorized user retrieve the required original and settlement context without creating a new amount due? For a completed delivery, ask whether historical consultation leaves current stock and fulfillment work unchanged. Inspect the target effect in the actual configuration.
If the only requirement is a monthly historical trend, define the reporting dataset and reconciliation separately. A report requirement may be satisfied without replaying individual operational documents. If users need drill-down to an original record, the reporting scope must include that retrieval route.
What does a usable historical archive require?
An archive needs an agreed retrieval job, controlled access and an owner who can keep that job working. Define how a user finds a record, what evidence must accompany it, and how access or recovery will be maintained. A folder of exported files is only a candidate until those requirements are demonstrated.
Here, “archive” means the retained-history destination agreed by the project. It does not mean running SAP’s Data Archive Wizard. The SAP Business One 10.0 archive guide describes irreversible data removal and excludes Browser Access and SAP HANA from that wizard’s support.
Write a retrieval task that another person can perform. For example: “For company A and invoice PAID-17, retrieve the original invoice, its required attachment and the reference explaining settlement.” Agree what counts as a correct result and record the location of each piece. This is an example specification, not a completed archive test.
Test a second company with the same visible invoice number. The result should remain within the requested company scope. Also include a missing attachment and a user without the necessary access. A search that returns something quickly can still return incomplete evidence or expose another company’s record.
Decide who maintains the retrieval service after the migration team leaves. That includes the access handover, the supported runtime if one is required, and a recovery exercise for the retained material. Obtain the necessary contractual and licensing confirmation for the chosen route; do not assume continued source-system access is automatic or free.
The relevant owners must set retention, deletion and any preservation obligations for the actual records and jurisdictions. This guide does not supply a universal retention period. Technical retrieval evidence supports that decision but does not establish legal compliance by itself.
What belongs in the migration scope register?
For each dataset, record the business purpose, exact inclusion boundary, destination, permitted effect and accountable owner. Add the evidence that will prove acceptance. Make exclusions explicit enough to review, and version the register so that a new cutoff or an added historical period cannot inherit approval from a different scope.
| Field | Question it answers | Example entry |
|---|---|---|
| Dataset and boundary | Which records are included? | Company A, open customer invoices at the approved cutoff. |
| Purpose and destination | What must a user do with them? | Continue collection work using the approved Odoo representation. |
| Allowed effect | What may change as a result? | Represent the remaining exposure once under the approved opening method. |
| Identity and evidence | How can a reviewer trace a record? | Company, source ID, target reference and reconciliation evidence. |
| Owner and acceptance | Who approves the result? | Finance approves the amount; operations demonstrates the next task. |
| Revision and exclusions | Which decision is being accepted? | Scope version, cutoff and explicitly excluded closed records. |
Download the proposed history-scope acceptance register. Its twelve cases cover operational continuation, the two open invoices, opening-position coordination, selected reference history and archive retrieval. They also include a changed cutoff and an unauthorized historical reposting case.
Every row is marked NOT_RUN. Replace the fictional records with approved test data and add actual evidence before anyone treats a row as accepted. The file is a starting specification, not a compatibility certificate or a completed reconciliation.
For the broader verification process, use the Odoo migration acceptance and reconciliation guide. Mapping suggestions have their own validation needs in the AI data-mapping review. The scope register decides which records and effects those checks must cover.
How should a scope change be accepted?
Treat a scope change as a new decision about dependent records and target effects. Name the additional job, identify what evidence becomes stale, and obtain the relevant owners' approval after the revised checks. Adding historical years can change relationships and financial behavior even when the extraction query changes only slightly.
Suppose someone asks to add all paid invoices from an earlier year. Ask whether the purpose is customer service, reporting or an active financial workflow. Then choose a representation and inspect its effect. A successful test for open invoices does not demonstrate that paid historical invoices are safe to replay through the same path.
If the required source access is unavailable, resolve that constraint before promising a complete history. The legacy ERP access-options guide covers the integration decision. Missing access should be an explicit scope dependency with an owner, not an undocumented assumption about what an export will contain.
What would we approve before building the import?
Approve a small scope register that covers the first operational tasks, the finance-approved opening position and a demonstrated route to retained history. Give each area a named owner. Build and evaluate the import against that agreement, then widen the scope only when another user job justifies the additional records and evidence.
Our recommendation is to start with one representative open-document chain and one closed-history retrieval task. They make the differences visible early: continuing work, preserving financial meaning and retrieving evidence are separate acceptance jobs. A legacy modernization assessment can turn those decisions into a bounded migration work package. Use the standard-versus-custom decision guide when choosing the retained-history implementation.