QuickBooks and Zoho Books migration workbook with USD reconciliation

Open a controlled migration run register

Create a run register with migration ID, source product and version, organization or company file, extraction owner, mapping version, configuration version, source extract hash or reference, import environment, operator, start and end timestamps, and approval status. Keep original extracts immutable and work on copies. Never place credentials or full employee records in the workbook.

Add a control-total sheet by object: accounts, contacts, items, taxes, open invoices, open bills, credits, payments, inventory, and bank transactions. Record source count, accepted count, rejected count, excluded with approval, and target count. Counts identify reconciliation work; they do not prove correctness.

Complete the migration run control fields:

• Migration ID and source product/version: Client entry: ______________________________
• Organization or company file: Client entry: ______________________________
• Mapping and configuration versions: Client entry: ______________________________
• Source extract hash/reference and owner: Client entry: ______________________________
• Import environment, operator, and timestamps: Client entry: ______________________________
• Baseline, corrected replay, and approval status: Client entry: ______________________________

Routine evidence is a complete extract with signed object counts. Exceptions include unavailable export fields, duplicate source rows, and rejected dependencies. Acceptance requires every rejection and exclusion to have a reason, owner, correction, and replay result. A successful technical import without that trail is not a completed migration.

Profile QuickBooks and Zoho Books separately

For QuickBooks, record product and version, company files, locations, classes, inventory method, currencies, sales-tax setup, payroll arrangement, and connected apps. For Zoho Books, record organizations, modules, branches, custom fields, workflows, currencies, and integrations. Do not use one assumed export schema for both families.

Create a source-profile worksheet with entity, object, available extract or API, field list, history range, known limitation, and source owner. Identify which fields support tax, exemption, branch, reporting, and reconciliation decisions. For Zoho Books custom fields, add type, allowed values, and workflow meaning. For QuickBooks classes and locations, document whether they map to analytic accounts, branch structures, or another approved reporting structure.

Routine evidence includes the actual sample export and corresponding native report. Exceptions include incompatible custom-field types, missing open-item links, and organization-specific semantics. The actual extract determines the transformation design; no universal connector or automatic migration is assumed.

Assign external IDs and dependency positions

Create an identity worksheet with source system, organization, object, source ID, external ID, target ID, mapping version, and reviewer. Names and labels are not stable unique identifiers. Preserve external IDs through every rehearsal and final run so reruns do not duplicate targets.

Create a dependency worksheet with sequence, object, parents required, allowed action on missing parent, owner, and evidence. Configuration and chart decisions precede contacts, items, and taxes; open documents follow their parties and accounts; payments and credits follow documents; inventory and bank reconciliation follow their base records. Custom fields required for downstream rules are validated before dependent imports.

Copy this identity and dependency worksheet once per source object:

• Source object: Client entry: ______________________________
• Source ID: Client entry: ______________________________
• External ID: Client entry: ______________________________
• Dependency position and parents: Client entry: ______________________________
• Mapping version and reviewer: Client entry: ______________________________
• Replay result: Client entry: ______________________________

Routine case: a complete parent chain imported once and replayed safely. Exceptions: a missing account, duplicate contact, inactive item, cross-organization reference, and a payment whose invoice was rejected. Dependent documents stop under a documented rule; they are not silently imported against an unapproved substitute parent. The external-ID session is educational only, not Oakland customer or US product evidence.

Map fields and tax meaning explicitly

Build a field dictionary with source field, sample value, transformation, target field, required status, owner, and decision. Mark each field as migrate, derive, ignore with approval, or unresolved. Include source custom fields, addresses, exemption references, branch identifiers, and integration IDs. Keep raw values in the control extract.

Create a tax-mapping sheet from source code to adviser-approved Odoo tax or fiscal position and jurisdiction evidence. The US has no broad-based federal general sales tax; state and local treatment varies, and federal excise remains separate. Use the CRS overview and USA.gov state-tax directory as research entry points, then record current jurisdiction sources.

Test taxable, exempt, expired-certificate, destination-change, shipping, and refund cases. If AvaTax is used, it supports tax calculation once an Avalara account, license, and configuration are in place. Follow the Odoo 19 AvaTax boundary: calculation does not determine nexus, registration, filing, or remittance, and excise tax is unsupported. Historical source tax results remain available for comparison even when future configuration changes.

Record exchange-rate and USD conversion evidence

For every foreign-currency sample, record source document, transaction currency and amount, exchange-rate value, rate date, rate source, accounting date, expected USD, and reviewer. Use the Odoo 19 multi-currency guide to design rate and exchange-difference tests. No rate provider is assumed without client approval.

Separate document-date rate, payment-date rate, and approved accounting policy. Include foreign-currency invoice, partial payment, credit, and final settlement so realized differences can be reconciled. Preserve raw values rather than overwriting them with a derived USD figure.

Routine acceptance matches expected and actual USD and explains exchange-difference entries. Exceptions include missing rate, changed rate source, payment on a different date, and an offsetting credit. Each difference receives a reason, owner, and approved treatment; a residual is not hidden by changing the source amount.

Test actual precision settings and residual ownership

USD normally appears with cents, and 31 USC 5101 recognizes dollars, cents, and mills. That does not mean every calculation is rounded to two decimal places. Odoo's currency rounding factor, product and pricelist precision, tax calculation's round-per-tax and round-per-line options, cash rounding, and currency-conversion behavior are assessed separately. Payment and foreign-currency reconciliation are tested separately; no independent payment-rounding or FX-rounding setting is assumed. Use cash-rounding guidance for the cash-specific case.

Build a precision and rounding matrix with input, currency rounding factor, product or pricelist precision, tax round-per-tax or round-per-line setting, cash-rounding rule, expected result, actual result, residual, and approval. Include 0.01, 0.04, 0.05, 0.09, -0.01, -0.04, -0.05, -0.09, large values, and mixed documents. Test per-line and per-document effects where relevant.

Copy this precision and rounding worksheet once per test document:

• Input and document: Client entry: ______________________________
• Currency rounding factor: Client entry: ______________________________
• Product/pricelist precision: Client entry: ______________________________
• Tax round-per-tax/line: Client entry: ______________________________
• Cash-rounding rule: Client entry: ______________________________
• Expected USD: Client entry: ______________________________
• Actual USD: Client entry: ______________________________
• Residual and owner: Client entry: ______________________________

No blanket tolerance is permitted. Even a difference of one cent needs a documented reason and owner when it changes a control total. Acceptance evidence includes signed expected and actual comparisons, configured rules, and residual disposition, never guaranteed two-decimal migration accuracy.

Reconcile open items, banks, and provider settlement

For each open invoice or bill, preserve original document, line and tax totals, payments, credits, remaining balance, and target link. Reconcile total open receivables and payables and then drill into partial payments, cross-period credits, and unapplied amounts. An equal aggregate balance can still conceal broken document links.

For bank accounts, record statement ending balance, book balance, unreconciled items, feed range, and required history. Bank synchronization depends on institution and provider and does not guarantee real-time or full history. Import gaps with controlled statements and test duplicate, delayed, and missing transactions.

For providers, reconcile gross sales, refunds, fees, and net settlement to provider and bank evidence. NACHA and ISO 20022 generation is not payment; bank upload, approval, and final statement are separate. Customer ACH receipt uses Authorize.Net eCheck or Stripe online-payment integrations; outgoing NACHA files and Wise vendor payments are separate. The bank-history session is general education only and not an Oakland reference or proof of institution support.

Reconcile inventory and late landed costs

Create an opening-inventory sheet with item, external ID, category, unit, warehouse, quantity, cost, total value, valuation account, and reviewer. Map service and non-stock items separately from stock items. Include lot and serial data where required and preserve units and conversions.

Reconcile quantity and value by item and warehouse to source and general ledger. Test a partial receipt, a partial sale, a return, and an item with a late freight or duty bill. The inventory-migration session and landed-cost session are educational only; their companies are not Oakland references.

Use Odoo 19 landed-cost documentation for eligible documents, allocation, and accounting. AVCO/FIFO prerequisites apply where required; Standard Price needs a separate validated path. Late charges and valuation differences remain exceptions until journal entries and reviewer approval are complete.

Assemble and sign the acceptance pack

The acceptance pack contains the run register, source and control totals, mapping and rejection logs, trial balance, open receivables and payables, tax samples, USD and precision matrix, inventory quantity and value, bank balances, provider settlements, and document-payment links. Each section has a client reviewer and evidence reference.

Run a baseline import and at least one corrected replay in a controlled environment. Compare rejection reasons across runs and prove corrections do not duplicate targets. Operations owners execute real workflows while finance reviews the accounting result. Preserve screenshots, exports, and journal references as appropriate.

Complete the migration acceptance record:

• Acceptance control: Client entry: ______________________________
• Expected evidence: Client entry: ______________________________
• Owner and reviewer: Client entry: ______________________________
• Actual result and residual: Client entry: ______________________________
• Retest and sign-off: Client entry: ______________________________

Negative tests include duplicate source, missing parent, invalid tax mapping, missing rate, rejected address, provider outage, late landed cost, and rejected bank file. Severity, workaround, owner, and retest are recorded. Material open exceptions block cutover; import percentages and upbeat summaries do not override them.

Control production cutover and post-cutover reconciliation

Freeze final mapping and configuration versions, name extraction cut-off, production importer, reconciliation owner, rollback owner, and business approver. Decide how transactions created after the final source extract are handled and preserve read-only access to final source reports.

After production import, repeat trial-balance, open-item, tax, inventory, bank, and provider reconciliation. Review the first operational and branch close. Classify issues as source data, configuration, provider, training, or new scope, and keep their evidence separate. Do not change mapping rules informally during final execution.

Continue with discovery and tax readiness, branch/POS go-live, and role-based training. Compare the source-specific guides for QuickBooks and Zoho Books. All OXP links in this guide are educational only; session companies are never Oakland references and later-version demonstrations are not Odoo 19 proof. Reviewed 2026-11-06.