Role-based Odoo 19 training plan for US teams

Build the role, permission, and assessment matrix

Create a row for each learner with synthetic trainee ID, role, legal entity, branch, work jurisdiction, required tasks, Odoo access, approver, sandbox availability, assessor, and remediation owner. Keep real employee identifiers, payroll values, and credentials outside the training pack.

Define cashier, branch manager, receiver/counter, purchaser, accountant, controller, payroll reviewer, treasury/payment operator, and administrator tracks. Access follows assigned work rather than a shared administrator login. Every track has one routine lab, one exception lab, and observable evidence required for sign-off.

Use US English task cards while retaining the exact English Odoo screen labels users will see. Cards contain purpose, permission, input, steps, expected journal or operational result, exception, evidence, and escalation. A generic module tour or video view count is not competence evidence. The access-rights training session is educational only; its companies are not Oakland references.

Complete a task card for each role:

• Role, entity, branch, and work jurisdiction: Client entry: ______________________________
• Required access and approver: Client entry: ______________________________
• Routine task and expected evidence: Client entry: ______________________________
• Exception and escalation path: Client entry: ______________________________
• Assessor, result, and remediation: Client entry: ______________________________

Train cashiers through sale, refund, and recovery

The cashier routine covers login, customer selection when online, product sale, reviewed tax treatment, tender, receipt, invoice request, and session close. The task card requires the order reference, payment reference, stock result, and expected close entry. Synthetic products and customers are used.

Exception labs include a refund linked to the original sale, mixed tender, declined payment, cash over or short, and an offline order. Odoo 19 POS guidance limits offline behavior: terminals, customer registration, and real-time stock need connectivity, and requested invoices follow reconnection.

The learner must explain why the browser session must remain open without reloading or clearing site data until synchronization completes: those actions can discard locally stored orders. The learner then compares local and server order counts, references, and statuses. Assessment includes payment, stock, and invoice reconciliation. A printed receipt alone does not pass. Remediation repeats the exact failed step rather than assigning another generic demonstration.

Train branch managers to own close and exceptions

The branch manager routine reviews opening float, staff access, sales and refund approvals, provider references, inventory movements, and daily close. The manager signs off on the expected-versus-actual cash reconciliation. They also confirm uninvoiced orders and provider gross and net amounts are separately reconciled.

Exception labs cover an expired exemption certificate, changed destination, provider outage, offline recovery, late landed cost, and rejected bank file. The manager records containment, owner, customer impact, and retest rather than deleting orders or forcing totals.

Tax training explains that state and local treatment varies, there is no broad-based federal general sales tax, and Wayfair sets no national threshold. Review physical-presence and economic-nexus paths for every applicable taxing jurisdiction, including local and home-rule administrations where relevant. Use the CRS overview and GAO review for discussion, with current adviser sources for actual decisions. The POS close session is educational only, not an Oakland customer reference.

Train receiving, counting, and purchasing roles

Routines for receivers, counters, and purchasers cover purchase orders, receipts, units and warehouses, vendor bills, returns, and stock and valuation reconciliation. Task cards require source document references and the expected quantity, value, and journal entry.

Exception labs include partial receipt, partial sale before a late freight bill, rejected vendor data, and a landed-cost allocation. Use Odoo 19 landed-cost documentation to verify eligible documents and allocation. AVCO/FIFO prerequisites apply where required; Standard Price needs a separately validated path.

The inventory migration session and landed-cost session are educational only and not Oakland references. Assessment requires quantity and value reconciliation and an explained journal result, not simply marking a receipt or vendor bill complete.

Train accountants and controllers on evidence and exports

Accounting routines include chart and tax review, invoice and bill posting, payment matching, USD reconciliation, report review, and close. Controllers additionally approve residuals, accounting policy, report mappings, and material exceptions.

Use the Odoo 19 US fiscal-localization page for l10n_us and l10n_us_reports, GAAP-oriented labels, direct cash flow, and check register. These starting structures do not guarantee GAAP, IRS, or SEC compliance. Learners reconcile journal entries to Balance Sheet, P&L, General Ledger, Cash Flow, and check register.

Exception labs cover 1099 missing or wrongly included items, USD precision residuals, foreign-currency settlement, and late landed cost. 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. IRS guidance explains the separate obligation and included-item review.

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. Multi-currency and cash-rounding references support those cases. Payment and foreign-currency reconciliation are tested separately; no independent payment-rounding or FX-rounding setting is assumed.

Train payroll reviewers on scope and third-party filing

Payroll reviewers learn the employee and jurisdiction matrix, work addresses, contract and wage inputs, employer versus employee taxes, trusted-bank readiness, and review of computed payslips. Synthetic employees and values are mandatory for training.

At review, Odoo 19 US payroll 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. Learners must escalate it rather than implying nationwide state and local payroll coverage.

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. Exception labs review included and excluded pay runs and third-party submission evidence. FUTA is employer-paid, not employee withholding. The ADP work-entry export is a CSV file for upload to ADP, not a direct API. Odoo can generate employee NACHA payment files, but generation is not bank upload, ACH processing, final settlement, tax deposit, or tax filing. Use IRS employment-tax guidance and filing and payment guidance for the employer responsibility discussion.

Train treasury/payment operators on step separation

Treasury routines cover bank statement import, feed review, payment batch, reconciliation, and exception ownership. Feed availability and history vary by institution and provider; bank synchronization is not a real-time or full-history guarantee. Learners test duplicate, delayed, and missing transactions.

NACHA and ISO 20022 labs separate generated file, bank upload, bank approval, and final statement. Customer ACH receipt uses Authorize.Net eCheck or Stripe online-payment integrations; outgoing NACHA files and Wise vendor payments are separate. The Federal Reserve ACH overview provides network context, while the US localization describes the workflows.

Exception labs include a rejected bank file, provider decline, fee difference, and delayed settlement. The learner reconciles gross, fee, and net amounts to provider and bank evidence. A feed, generated file, or Odoo status never counts as payment or settlement proof. The bank-history session is educational only.

Train administrators on access, secrets, and evidence custody

Administrator routines cover role-based access, module and version inventory, test-user management, audit review, backup and restore evidence, and escalation. Production administrator access is not shared for convenience. Training environments use synthetic data and separately owned credentials.

Credential cards record only custodian, secure reference, renewal date, emergency access, and revocation procedure. Avalara keys, bank credentials, API tokens, private keys, SSNs, and full bank details never appear in the training pack. Provider owners enter secrets through the approved channel.

Exception labs cover revoked credential, unavailable provider, restore rehearsal, and an unauthorized-access review. Hosting evaluation uses Odoo hosting documentation for application compatibility, backups, restores, and external services. Hosting and data-residency requirements are assessed per project, and no US data-residency guarantee is made by the standard offer. Administrators sign the access and evidence-custody checklist before go-live.

Assess competence and hand over to champions

Each assessment records trainee, task, environment, input, expected result, actual result, evidence, assessor, gaps, remediation, and retest. Passing requires both routine and exception execution with correct escalation. A quiz or attendance record can supplement but not replace the practical evidence.

Complete the practical assessment record:

• Trainee, role, and sandbox: Client entry: ______________________________
• Routine task and expected result: Client entry: ______________________________
• Exception and expected escalation: Client entry: ______________________________
• Actual evidence and assessor: Client entry: ______________________________
• Gaps, remediation, and retest: Client entry: ______________________________

Champions review task cards, terminology, and common exceptions for their branch and role. They accept first-line coaching ownership, escalation routes, and the process for proposing card updates. Version or provider changes trigger review of affected cards rather than silent reuse.

The rehearsal and hypercare session and POS hardware session are optional implementation education. Session companies are never Oakland references, and later-version demonstrations do not prove Odoo 19 behavior. Any Odoo 20 material, including the release notes, stays outside the Odoo 19 capability baseline.

Use adoption evidence to close training and hypercare

Review branch close, reconciliation residuals, access issues, repeated user errors, and support themes. Retrain against the failed task and its evidence rather than adding more generic presentations. Hypercare exit depends on stable operation, owned residuals, working escalation, and champions in place.

Maintain a source-review log for Odoo version, tax, payroll, bank, provider, and hardware changes. E-invoicing training is scoped by counterparty: there is no universal US private-sector e-invoicing or Peppol mandate, and the reviewed Odoo 19 EDI documentation does not document native US Peppol registration, Treasury IPP connectivity, or US-specific EDI localization. IPP and OMB M-15-19 apply only to their specific federal context.

Continue with discovery and tax readiness, migration and USD reconciliation, and branch/POS go-live. Every OXP link in this guide is educational only; session companies are not Oakland references or evidence of US customers, staff, or outcomes. Reviewed 2026-11-06.