Custom Reports in an Odoo Migration: Build to Requirements, Then Prove the Numbers Match

On most migrations, the data loads and the modules work, and then someone from finance opens a report and asks a simple question: "Why doesn't this match what I had in QuickBooks?" That moment decides whether the team trusts the new system. Reports are where migrated data becomes numbers people make decisions on, so they are the real acceptance test of the project.

This article covers three things: how to configure reports around what the business actually needs, how to make sure they carry both the accounting and the operational information people rely on, and how to validate the results against the migrated QuickBooks data before go-live.

Start With the Reports People Actually Use

The most reliable requirements source is not a workshop wish list. It is the set of reports the client already runs in QuickBooks. Ask each team which reports they open weekly and monthly, what decision each one supports, and which fields or groupings they depend on. A report nobody can explain a use for is a candidate to drop. A report that only one person knows how to run is a risk worth documenting.

For each report on the list, decide where it will come from in Odoo. Many are covered by standard reports: Odoo ships accounting reports such as the trial balance, general ledger, and aged receivables and payables, and most apps offer list, pivot, and graph views for analysis. Only what is left over needs a custom build. That order matters, because every custom report is something you must build, test, document, and maintain through future upgrades.

Cover Both Accounting and Operational Information

A common gap is a report set that satisfies finance but leaves operations guessing, or the reverse. Accounting reports answer "what is our position": balances, receivables and payables, profit and loss, and the ledger behind them. Operational reports answer "what needs to happen next": open orders, open purchase orders, stock levels, and work still in progress.

The two need to agree with each other. If an operational report shows a set of open sales orders, the accounting side should show the same customers' receivables moving in a way that makes sense. When a requirement is really about a business decision, such as which customers are overdue and what they owe, build the report around that question and check that it draws on the same underlying data as the accounting view. Two reports that use different definitions of "outstanding" will eventually produce an argument.

Validating Against the Migrated QuickBooks Data

Validation only works if you compare like with like. Pick one cutoff date, take the QuickBooks figures as of that date from a saved extract, and run the Odoo report with the same filters and the same date. If you extract QuickBooks data through ODBC, the same saved query can be re-run later, which makes the baseline repeatable. We cover that setup in our guide to ODBC connectivity for QuickBooks migrations.

Compare totals first, then drill down. If the trial balance ties, move to receivables and payables per customer and vendor, then to transaction-level checks on a sample. If the totals do not tie, the fastest route is usually to split the difference by account, by month, or by partner until the gap points at a specific cause.

Some differences are legitimate. A record merged or cleaned up during migration will not look identical to the original, and that is fine as long as the reason is documented and the report owner accepts it. What you cannot accept is an unexplained variance, even a small one, because it means something in the data or the report logic is not understood.

Our Recommendation: Sign-Off Per Report, Before User Testing

There are two ways to run report validation. You can leave it to user acceptance testing and let users spot problems as they explore, or you can run a structured tie-out first and hand users reports that are already proven. We recommend the structured tie-out, with a named owner approving each report.

The reason is cost. A variance found by a finance user during acceptance testing is usually found late, discovered inconsistently, and argued about. The same variance found in a planned tie-out is found early, against a defined baseline, and fixed while the data-loading process is still fresh in everyone's mind. Users still test, but they test whether the report is useful, not whether the numbers are right.

A Report Readiness Checklist

• List every report the client runs in QuickBooks, who uses it, and what decision it supports.
• Map each one to a standard Odoo report first, and build custom only for the remainder.
• Write down the definition of each key measure and get the report owner to approve it.
• Fix a cutoff date and save the QuickBooks baseline extract for it.
• Tie out totals first, then per customer and vendor, then a transaction sample.
• Explain every variance, fix the data or the report, and record the outcome.
• Get sign-off from each report owner before user acceptance testing starts.

Final Thoughts

A migration can load every record correctly and still feel like a failure if the reports don't match what people expect. Build reports from the ones the business already relies on, cover both the accounting and the operational picture, agree definitions up front, and prove the numbers against QuickBooks with a repeatable tie-out.

Do that, and go-live day is not the first time anyone checks whether the numbers are right. It is the day people find out the new system tells them what the old one did.