US Odoo discovery and tax-readiness workbook

Create the workbook control sheet

Create a workbook with a release row containing workbook version, prepared by, client product owner, tax adviser, payroll reviewer, banking owner, provider owner, Odoo version, installed modules, and review date. Use synthetic or redacted samples. Never enter passwords, Avalara license keys, bank credentials, private keys, full employee records, or unnecessary personal data.

Add an entity register with one row per legal entity and a separate branch register. Fields include legal name, registration, EIN held by the authorized owner, base currency, ship-from addresses, warehouses, selling channels, employee work locations, bank accounts, payment providers, and current filing responsibilities. A branch is not silently treated as a legal entity.

Complete the workbook control fields:

• Workbook version and prepared by: Client entry: ______________________________
• Client product owner and reviewers: Client entry: ______________________________
• Odoo version and installed modules: Client entry: ______________________________
• Legal entities and registration references: Client entry: ______________________________
• Branches, warehouses, and work locations: Client entry: ______________________________
• Review date and source owners: Client entry: ______________________________

Routine evidence: one signed entity/branch map and current registrations. Exception evidence: an entity with multiple warehouses, a remote employee, and a marketplace plus direct-sales channel. Acceptance means every operational location has an owner and a decision route, not that every location creates the same tax or payroll treatment.

Build the transaction and jurisdiction worksheet

Use one row per representative sale, purchase, return, discount, shipping charge, and payment. Capture source document, entity, customer or vendor, product/service, ship-from, ship-to, transaction date, channel, currency, amount, tax result, exemption reference, sourcing decision, and reviewer. Attach a redacted invoice or source report reference.

The United States has no broad-based federal general sales tax. State and local rates, taxability, exemptions, sourcing, administration, and economic-nexus thresholds vary. Federal excise and other federal taxes remain separate. Cite the CRS overview, IRS business-taxes page, and USA.gov state-tax directory in the source column, then add current jurisdiction-specific sources supplied by the adviser.

Routine case: an adviser-reviewed taxable sale with destination and tax mapping. Exception cases: an exempt sale, a refund, a changed ship-to address, and a product with potential federal excise treatment. Acceptance evidence is the signed transaction mapping and journal result, not a generic “US tax configured” statement.

Separate physical-presence and economic-nexus evidence

Maintain separate physical-presence and economic-nexus paths for every applicable taxing jurisdiction, including local and home-rule administrations where relevant. State-only review is not sufficient. Wayfair does not create a universal national threshold. Use the GAO post-Wayfair report for implementation-variation context and the Wayfair opinion for the legal reference, not for a universal threshold or filing instruction.

Complete one physical-presence worksheet per applicable taxing jurisdiction:

• Jurisdiction: Client entry: ______________________________
• Physical-presence evidence: Client entry: ______________________________
• Current activity and location: Client entry: ______________________________
• Official source and review date: Client entry: ______________________________
• Registration and filing evidence: Client entry: ______________________________
• Adviser decision: Client entry: ______________________________

Complete a separate economic-nexus worksheet for the same jurisdiction:

• Jurisdiction: Client entry: ______________________________
• Economic-nexus threshold and measurement period: Client entry: ______________________________
• Direct and marketplace channels: Client entry: ______________________________
• Sourcing rules: Client entry: ______________________________
• Official source and review date: Client entry: ______________________________
• Registration and filing evidence: Client entry: ______________________________
• Adviser decision: Client entry: ______________________________

Create an exemption register with customer, exemption type, jurisdiction, certificate ID or controlled reference, issue and expiration dates, custodian, applicable products, and reviewer. Test a valid certificate, an expired certificate, missing evidence, and a partial exemption. Routine acceptance requires current evidence and correct document treatment. Exceptions require a stop/review outcome and an auditable resolution, never an automatic exemption assumption.

Prove the Odoo 19 US accounting baseline

Record the selected US package and installed modules. l10n_us supplies the base localization and l10n_us_reports adds US reports. The package provides a starting chart, configurable default sales and purchase taxes, GAAP-oriented labels and reports, direct-method cash flow, and a check register. Use the official US fiscal-localization page as the source.

Build a chart-mapping worksheet with source account, target account, account type, report section, tax or default mapping, owner, and approval. Do not delete preconfigured accounts merely to force a source structure; review renames and additions with the accountant. Validate direct-method cash-flow behavior using an unpaid vendor bill followed by its payment rather than assuming the bill alone creates cash flow.

Acceptance evidence includes package and version, chart approvals, sample journal entries, Balance Sheet, Profit and Loss, General Ledger, direct Cash Flow, and check register reconciliations. GAAP-oriented labels do not guarantee GAAP, IRS, or SEC compliance. The accountant signs off on the final configuration and documents unresolved report exceptions.

Configure and test AvaTax within its boundary

Create an Avalara readiness sheet with account owner, license status, environment, company code, fiscal country, addresses, jurisdictions, product mappings, exemption mappings, credential custodian, secure credential reference, and renewal or revocation procedure. AvaTax supports tax calculation once an Avalara account, license, and configuration are in place. Record no secret in the workbook.

Complete the AvaTax readiness fields without entering secrets:

• Account owner, license status, and environment: Client entry: ______________________________
• Company code and fiscal country: Client entry: ______________________________
• Addresses and taxing jurisdictions: Client entry: ______________________________
• Product and exemption mappings: Client entry: ______________________________
• Credential custodian and secure reference: Client entry: ______________________________
• Renewal, emergency access, and revocation procedure: Client entry: ______________________________

Use the Odoo 19 AvaTax guide. Test connection, address sourcing, product and category mapping, a reviewed exemption, credit note, rejected address, provider unavailability, and commit or non-commit behavior selected by the client. Keep request IDs and non-sensitive response evidence. Confirm who reviews any transaction committed to Avalara reporting.

Calculation is not nexus determination, registration, filing, or remittance. The documented integration does not support excise tax. Add a stop row for any excise candidate and assign it to the tax adviser. Acceptance requires both the technical response and the adviser's tax decision, plus a tested fallback when the provider is unavailable.

Review information returns and federal obligations separately

Create a 1099 review sheet with vendor, non-employee status, payment period, source journal items, included amount, exclusions and reason, reviewer, CSV version, and third-party submission reference. The 1099 export supports applicable IRS information-return workflows through a third-party filing service. It is not automatically submitted to the IRS or any state or local authority. Use the IRS information-return guidance.

Add missing-item and wrongly included-item tests. Reconcile the CSV total to the approved payment population and preserve the third-party acceptance or rejection response. The export does not prove that every required vendor or payment is included.

The W-2 export supports third-party SSA submission. The Form 940 and Form 941 exports support third-party IRS submission. State and local filing obligations, forms, channels, data, and acceptance evidence are assessed separately and are not implied to use those federal exports. None of these exports files automatically. Create a federal obligations register covering relevant income, employment, and excise topics with responsible adviser, return or deposit channel, and evidence. Use filing and paying business taxes and employment-tax guidance. FUTA is employer-paid, not employee withholding. State and local sales-tax rows and federal-tax rows remain distinct.

Gate payroll scope by employee and jurisdiction

Create an employee-jurisdiction matrix using synthetic employee IDs. Include employer entity, work address and state, residence where relevant, pay type, benefits, filing status fields, trusted-bank readiness, state and local reviewer, and decision. Do not include SSNs, full bank details, or real payroll values in this workbook.

At review, the Odoo 19 US payroll-localization page lists exactly AL, AZ, CA, CO, FL, GA, ID, IL, IA, MS, NV, NJ, NY, NC, OR, TX, VT, VA, WA and DC. An unsupported payroll work jurisdiction must be flagged before configuration and assessed separately. Nationwide state and local payroll coverage is not implied.

Test the W-2, Form 940, and Form 941 exports with included and excluded pay runs and retain the third-party submission evidence described above. The ADP work-entry export is a CSV file for upload to ADP, not a direct API. Review its work-entry code mapping. Odoo can generate employee NACHA payment files, but generation is not bank upload, ACH processing, final settlement, tax deposit, or tax filing. Acceptance requires payroll-specialist approval, payment and filing evidence owned separately, and clear treatment of employer-paid FUTA versus employee withholdings.

Inventory banking, payment, and e-invoicing dependencies

For every bank and payment flow, record institution, account type, provider, integration, currency, available history, fee treatment, settlement account, cut-off, and approval owner. The bank-synchronization guide does not justify real-time, complete-history, or universal-coverage claims.

Separate NACHA file creation, bank upload, bank approval, and statement settlement. Separate ISO 20022 XML generation from outside-Odoo upload and approval. Wise completion occurs in Wise. Customer ACH receipt uses Authorize.Net eCheck or Stripe online-payment integrations; outgoing NACHA files and Wise vendor payments are separate. Use the Federal Reserve ACH overview for context and test delayed, duplicate, and rejected activity.

For e-invoicing, record counterparty type, agency or private trading partner, required format or channel, and provider. There is no universal US private-sector Peppol mandate. Federal agency IPP and procurement requirements are specific: review OMB M-15-19 and IPP. The reviewed Odoo 19 EDI documentation does not document native US Peppol registration, Treasury IPP connectivity, or US-specific EDI localization. Provider or custom work requires its own estimate and counterparty acceptance.

Run routine and exception acceptance scenarios

Build an acceptance matrix with scenario ID, requirement, configuration and version, input sample, expected accounting and operational result, actual result, evidence link, severity, owner, and sign-off. Include at least one routine case for each workstream and the exceptions from earlier worksheets.

Copy this acceptance worksheet once per scenario:

• Scenario: Client entry: ______________________________
• Expected result and control: Client entry: ______________________________
• Evidence owner and link: Client entry: ______________________________
• Actual result and residual: Client entry: ______________________________
• Severity and next action: Client entry: ______________________________
• Sign-off: Client entry: ______________________________

Minimum scenarios include ordinary sale, exempt sale with valid evidence, expired certificate, interstate destination change, refund, AvaTax outage, 1099 missing or wrongly included item, unsupported payroll jurisdiction, duplicate bank transaction, rejected NACHA or ISO file, late landed cost, and an agency e-invoicing applicability decision. Use landed-cost guidance for the late-landed-cost scenario and test AVCO/FIFO prerequisites where required; Standard Price needs a separate path.

A failed case remains open with a named owner and next action. “No error on screen” is not acceptance. The matrix is complete only when the accounting, operational, and professional evidence agrees or an exception is explicitly accepted by the accountable owner.

Approve the blueprint and maintain the source trail

Hold a blueprint review with the client product owner, accountant, tax and payroll advisers, banking and provider owners, and Oakland. Approve requirement classifications, standard versus provider versus custom work, migration scope, client responsibilities, test evidence, and stop conditions. Record unresolved decisions with owners rather than hiding them in assumptions.

Set a source-review cadence for Odoo version changes and current jurisdiction or provider changes. The Odoo 20 release notes are a version fence only: the redesigned US Sales Tax Report and NYC/Yonkers payroll additions do not enter Odoo 19 claims. Hosting and data flows are assessed using Odoo hosting documentation, without a US residency promise. 31 USC 5101 recognizes dollars, cents, and mills but does not set one application-rounding rule. 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.

Continue with USD migration and reconciliation, branch/POS go-live, and role-based training. For general delivery education, the finance-first discovery session and multi-company controls session are optional only. Session companies are not Oakland references and prove no US capability or statutory outcome. Reviewed 2026-11-06.