Multi-state branch and Odoo 19 POS go-live checklist

Create a branch and cutover control register

Use one row per POS device. Record legal entity, branch, warehouse, ship-from jurisdiction, address, selling channel, tax reviewer, manager, network owner, opening date and time, time zone, cash drawer, receipt printer, scanner, payment terminal, browser, and fallback contact. Distinguish legal entities from locations and do not infer uniform treatment from a shared brand.

Add a cutover register with pilot branch, configuration version, source-data version, opening-inventory approval, training completion, network and hardware evidence, provider readiness, go or no-go approver, and rollback owner. Freeze the approved branch template before rollout. Later sites inherit only reviewed settings, with local exceptions recorded.

Copy this worksheet once per POS device and complete every client-entry area:

• Legal entity: Client entry: ______________________________
• Branch: Client entry: ______________________________
• Warehouse: Client entry: ______________________________
• Ship-from jurisdiction: Client entry: ______________________________
• POS device and browser: Client entry: ______________________________
• Network and peripheral tests: Client entry: ______________________________
• Opening owner and fallback: Client entry: ______________________________
• Approval and evidence link: Client entry: ______________________________

Routine evidence is a signed branch and device inventory and approved opening controls. Exceptions include a new state, different hardware, a marketplace channel, or a branch with an unsupported payroll jurisdiction. Go-live does not proceed on a generic “multi-state ready” claim.

Prove network, browser, printer, and peripheral compatibility

At each site, test the actual network, browser version, receipt printer, scanner, cash drawer, customer display, and payment terminal. Record device model, connection, browser and device pairing, test user, output reference, result, and fallback. Keep check-paper testing separate from POS receipt testing.

Run a normal receipt, a reprint, a barcode scan, a drawer open where permitted, a network interruption, and a recovery. Verify required business and transaction fields are readable on the receipt. Use synthetic transactions and controlled test credentials. Do not clear browser data or reload during an unresolved offline-order exercise.

The POS network and hardware session is implementation education only; session companies are not Oakland references or proof of a client's device compatibility. Designated branch staff capture site-specific device-test evidence, including models, browser versions, test output, and fallback results, rather than relying on a list of theoretically supported devices.

Review tax, exemption, and source documents per branch

Create a branch transaction sheet with product or service, ship-from, ship-to, customer type, exemption evidence, sourcing decision, tax treatment, and jurisdiction source. State and local rates, taxability, exemptions, sourcing, administration, and economic-nexus thresholds vary. There is no broad-based federal general sales tax, and federal excise remains separate.

Use the CRS overview, state-tax directory, and GAO review to frame current adviser research. Wayfair does not set a national threshold. Review physical-presence and economic-nexus paths for every applicable taxing jurisdiction, including local and home-rule administrations where relevant, with separate thresholds, measurement periods, sourcing, marketplaces, registration and filing evidence, official sources and review dates, and adviser decisions. State-only review is not sufficient.

AvaTax supports tax calculation once an Avalara account, license, and configuration are in place. It does not determine nexus or filing obligations, and the documented integration does not support excise tax. Test an adviser-reviewed taxable sale, exempt sale with valid evidence, expired certificate, changed destination, refund, and excise stop case. Preserve receipt, calculation response, and journal evidence. Calculation and a printed receipt do not prove registration, filing, or compliance.

Rehearse opening cash, routine sales, and refunds

For each shift, record opening float by denomination or approved aggregate, cashier, manager approval, POS session, and starting bank or cash balance. Do not treat the opening entry as a verified count until the cashier and reviewer sign it.

Run a routine sale with one tender, a mixed-tender sale, a customer invoice request, a return, and a cash over or short scenario. Capture order reference, line and tax totals, payment references, stock movement, receipt, invoice status, and journal entries. For credit and refund workflows, link the original order and the reason and approval required by the client.

At close, count cash independently, compare expected and actual amounts, and record variance reason and owner. Reconcile uninvoiced orders and invoiced orders separately. A session total is not accepted until payment, stock, invoice, and cash evidence agree. This is the daily control baseline used for every later exception review.

Validate customer ACH and provider settlement end to end

Odoo 19 documents customer ACH receipt through Authorize.Net eCheck and Stripe online-payment integrations, and vendor direct-deposit completion in Wise. Outgoing NACHA files and Wise vendor payments are separate. Stripe POS Terminal is a separate payment flow, not an outgoing vendor-payment mechanism. Provider support, merchant eligibility, currencies, fees, refunds, terminals, and settlement accounts vary. Create a provider sheet with merchant account, environment, integration, tender mapping, fee rule, settlement currency, cut-off, support owner, and evidence.

Test approved, declined, refunded, and delayed provider cases. Record provider transaction ID, POS or order reference, gross amount, fee, net settlement, bank deposit, and reconciliation owner. Do not infer settlement from an Odoo payment status or provider authorization.

The Federal Reserve ACH overview supplies network context. Wise completion occurs in Wise, and provider settlement must be matched to provider and bank evidence. Acceptance requires a signed gross-to-net reconciliation and exception procedure, not universal US payment coverage.

Separate check, NACHA, and ISO 20022 bank controls

US check layouts require their own paper, layout, and printer evidence. NACHA configuration uses institution-supplied values and generates a file for the bank. ISO 20022 XML is uploaded and approved outside Odoo. None of these steps proves that recipients were paid.

Create a bank-file control with journal, account, payment method, institution configuration owner, payment batch, generated file hash or reference, uploader, bank approver, approval timestamp, rejection reason, and statement match. Use the Odoo 19 US localization for workflow boundaries.

Test an accepted file, a rejected file, a duplicate-prevention case, and a correction under bank instructions. Keep generated file, upload confirmation, bank approval, and final statement as separate artifacts. Do not store bank credentials in the checklist. Acceptance requires the final reconciliation, not just a valid-looking file.

Rehearse offline capture and reconnection safely

Odoo 19 POS guidance supports order handling during a temporary outage with later synchronization. Payment terminals, customer registration, and real-time stock need connectivity, and requested invoices are generated after reconnection. Local network availability does not change those limits.

Use a controlled browser profile and synthetic orders. Record offline start, orders created, tender behavior, customer and invoice limitations, and browser custodian. Keep the browser session open and do not reload it or clear its site data before synchronization completes, because those actions can discard locally stored orders. Later-version demonstrations, including this offline-limitations session, are educational only and not Odoo 19 proof or Oakland references.

After reconnection, wait for synchronization and compare local and server orders by count, reference, and status. Reconcile payments, stock, invoices, and uninvoiced orders before close. Investigate duplicates and missing orders without clearing local evidence. Sign the recovery only after the branch and finance owners agree.

Reconcile stock and landed-cost exceptions at the branch

Map each stock item, unit, warehouse, POS location, valuation account, and available-to-sell rule. Test an ordinary sale, refund, partial shipment, and a stockout or backorder decision. Offline stock information may be stale, so the branch exception procedure must say when to stop or manually verify.

For freight, insurance, duties, and other charges, record the eligible receipt and vendor bill, allocation basis, valuation method, and journal result. Use Odoo 19 landed-cost documentation. AVCO/FIFO prerequisites apply where required; Standard Price needs a separately validated route.

Test a late charge after some stock has sold and reconcile quantity and value to the general ledger. The landed-cost session is educational only, not Oakland or US evidence. Acceptance requires signed inventory and accounting reconciliation, not merely a receipt marked done.

Execute the daily close and exception playbook

The close checklist includes local and server order count, invoiced and uninvoiced orders, payment tenders, provider gross and net settlement, cash count, stock movement, tax review, journal entries, and bank-file status. Each line has expected value, actual value, difference, reason, owner, and approval.

Complete the daily close worksheet:

• Close control: Client entry: ______________________________
• Expected amount or state: Client entry: ______________________________
• Actual amount or state: Client entry: ______________________________
• Difference and reason: Client entry: ______________________________
• Owner and approval: Client entry: ______________________________
• Evidence link: Client entry: ______________________________

Run cash over or short, declined provider payment, refunded order, offline recovery, duplicate-feed transaction, late landed cost, and rejected bank file. Record severity, customer impact, immediate containment, correction, and retest. Do not clear browser data, delete orders, or force a reconciliation to make the close balance.

Use the POS-to-finance close session as general education only; session companies are not Oakland references. Branch and finance owners sign the close after differences are resolved or explicitly assigned. An open material exception prevents the next rollout wave.

Approve rollout waves and adoption evidence

Start with a pilot that represents the actual network, hardware, transaction, and staff constraints. Freeze its accepted template, then approve each later branch against local evidence. A new state, provider, device, or tax scenario triggers targeted retesting rather than an assumption of universal coverage.

Training completion is practical: cashier sale, refund, and offline recovery; manager close and exception approval; inventory receipt and late cost; and finance provider and bank reconciliation. Record assessor and remediation. Hypercare triage separates hardware, network, provider, data, configuration, and training issues.

Continue with discovery and tax readiness, migration and USD reconciliation, and role-based training. The Odoo 20 release notes are only a version fence and do not add Odoo 19 POS, tax, or payment capabilities. All OXP links here are educational, never Oakland references. Reviewed 2026-11-06.