A USD proposal framework tied to scope and acceptance evidence
Oakland separates fixed-fee discovery, fixed-scope implementation phases, and post-launch adoption work. Proposals can be denominated in USD where commercially agreed, with each fee following the approved scope and acceptance criteria. Reviewed 2026-11-06.
Discovery and US readiness blueprint
Turn real transactions, extracts and operating constraints into a controlled scope.
- Entity, state, transaction, payroll and provider inventory
- QuickBooks or Zoho Books source and data-quality assessment
- Prototype workflows and explicit standard, provider and custom boundaries
- Acceptance matrix, responsibilities and phased implementation blueprint
Implementation and migration phases
Price approved phases against configuration, rehearsal and signed acceptance.
- Configuration and separately identified custom-development exceptions
- Repeatable migration, USD reconciliation and residual review
- Branch, POS, provider, bank and hardware acceptance evidence
- Role-based training, cutover rehearsal and change control
Adoption and optional support
Separate early adoption evidence, ongoing support and new scope.
- Named triage ownership for defects, decisions and reconciliation residuals
- Branch-close, training and adoption evidence before hypercare exit
- Clear separation of support, new requirements and provider work
- Odoo subscriptions, third parties, hardware and client effort kept visible
These are commercial stages, not published packages or totals. The approved discovery record, migration scope, provider and bank decisions, hardware, custom work, acceptance evidence and client responsibilities determine each proposed USD fee.
What a USD proposal must make visible
A useful proposal shows the work and assumptions behind each fee. It identifies entities, branches, warehouses, user roles, transaction volumes, operating states, current systems, history depth, currencies, banks, payment providers, payroll locations, hardware, and required acceptance evidence. It also states who supplies clean data, professional decisions, provider accounts, test users, and final approval.
The three commercial stages are not fixed-price packages. Discovery establishes the blueprint, implementation phases are priced against that blueprint, and adoption and optional support have their own operating terms. A proposal can use USD where commercially agreed, but a currency label is not a price or a promise of scope. Package totals are established only after discovery defines the work.
The proposal separates Oakland services from the Odoo subscription, third-party licenses, bank and payment charges, hardware, infrastructure, and client internal effort. Any custom development is identified rather than hidden inside a generic implementation line.
Discovery is a defined paid work product
Fixed-fee discovery begins with an agreed input list and named reviewers. The client supplies representative transactions, source extracts, current reports, state and payroll locations, provider details, non-sensitive hardware information, and process owners. Credentials, full employee records, and unnecessary personal data are not requested through the lead form.
Discovery workshops map current workflows and classify each requirement as standard Odoo 19, configuration, third-party service, custom development, client procedure, or unresolved decision. Important assumptions are tested in a prototype based on the client's actual workflows. Tax and payroll treatment remains with qualified advisers; bank and payment support remains with the relevant institutions.
The paid outputs are a process and data inventory, prototype evidence, requirement and exception register, migration assessment, acceptance matrix, responsibilities, and phased blueprint. Those outputs define what can be priced. They do not guarantee a statutory outcome, migration result, or implementation duration.
Implementation phases follow the approved blueprint
Each implementation phase has a scope boundary, configuration list, identified exceptions, dependencies, test cases, and acceptance owner. Finance, sales, purchasing, inventory, POS, payroll, and integrations are not bundled as if every business needs the same modules. A phase can be deferred when its provider, adviser, hardware, or data prerequisite is unresolved.
Standard-first design does not mean zero customization. Generic requirements use standard capability where it fits. A justified custom exception receives its own design, estimate, test evidence, maintenance owner, and upgrade review. Provider configuration and custom development are separate from claims about core Odoo 19.
Change control compares a new request with the approved process and evidence. It records whether the request is a defect in agreed scope, a clarified assumption, new scope, or an external dependency change. Fees and sequence are adjusted only through that written decision, not through an implied unlimited implementation package.
Migration and USD reconciliation are separate work packages
Migration pricing depends on source products and versions, object counts, history depth, custom fields, data quality, open-item linkage, inventory valuation, currencies, and rehearsal requirements. QuickBooks and Zoho Books are assessed from actual extracts rather than a universal connector assumption.
The work package names extraction, cleansing, mapping, external IDs, dependency ordering, trial imports, rejection handling, reconciliation, and cutover support. Raw source currency and amount, exchange-rate source and date, expected USD, actual USD, debit and credit totals, rounding rule, residual, explanation, and sign-off remain visible.
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. Extra rehearsals, historical periods, late landed costs, and unresolved data remediation are explicit scope drivers.
Providers, banks, and payment costs stay outside a generic fee
AvaTax supports tax calculation once an Avalara account, license, and configuration are in place. Calculation does not determine nexus, register the business, file returns, or remit tax, and the documented integration does not support excise tax. The proposal identifies provider subscription or transaction charges separately from Oakland configuration and acceptance work. Review the Odoo 19 AvaTax boundary.
NACHA, customer ACH receipt, Wise vendor payments, and ISO 20022 workflows require institution- and account-specific validation. Customer ACH receipt uses Authorize.Net eCheck or Stripe online-payment integrations; outgoing NACHA files and Wise vendor payments are separate. File generation is not payment or settlement. Provider onboarding, bank charges, transaction fees, FX charges, approval services, and statement feeds are not silently included in an Oakland implementation fee.
Plaid or other feed work depends on Enterprise, provider and institution support, and available history. Payment-terminal and hardware support is validated per device and merchant flow. Any custom connector is estimated and maintained separately from standard capability.
Hardware, infrastructure, and client effort are explicit
POS scope lists printers, scanners, cash drawers, terminals, browser/device combinations, network work, and spare equipment where required. Compatibility evidence is collected at the branch. Check paper and layout testing is distinct from receipt testing. Hardware procurement, warranties, and replacement stock are not assumed to be included in services.
Hosting is selected after reviewing custom-app requirements, production and backup arrangements, restore tests, external-service transfers, and support responsibilities. No US data-residency promise is made. Infrastructure, third-party monitoring, and nonstandard networking costs are identified where applicable.
Client effort includes process owners, data extraction and cleansing, professional review, provider onboarding, test execution, training attendance, and operating approvals. A proposal records those commitments instead of treating client availability as free or unlimited. Delayed prerequisites become visible dependencies rather than hidden delivery risk.
Odoo subscriptions and version boundaries remain separate
Odoo subscription charges are paid under the customer's chosen Odoo arrangement and are separate from Oakland services. Use current Odoo pricing for the subscription discussion rather than copying a numeric figure into this framework. Enterprise-dependent options, third-party apps, and service credits are identified only when relevant to the approved design.
The implementation baseline is Odoo 19. Odoo 20 release notes can identify future evaluation work, but they do not prove an Odoo 19 feature or justify a current delivery line. The redesigned US Sales Tax Report and NYC/Yonkers payroll additions are not presented as Odoo 19 capability.
If an upgrade is requested, its assessment, custom-code review, provider compatibility, migration rehearsal, and acceptance are scoped separately from the initial implementation. No automatic upgrade, support duration, or future-version compatibility is promised.
Scheduling and support terms require an operating agreement
Oakland delivers projects remotely from the UAE. Meetings can be arranged around the client's agreed US time zone. Support hours and response times apply only when written into the operating agreement.
Early adoption support names triage channels, issue ownership, reconciliation review, branch-close evidence, and the distinction between defect, decision, and new requirement. Hypercare exit depends on adoption and operating evidence.
Ongoing support is optional and separately scoped. Service windows, channels, escalation paths, and response expectations belong only in the approved operating agreement. New features, provider changes, new entities, tax-policy changes, and custom development are evaluated separately from defect support.
Proposal review and acceptance checklist
Before approving a proposal, confirm that every commercial line answers a concrete question. Discovery inputs and outputs are named. Phase scope and exclusions are readable. Migration objects, history, and rehearsals are listed. Provider, bank, hardware, and client responsibilities have owners. Custom work and its maintenance boundary are explicit.
Check that tax, payroll, and statutory review is assigned to qualified advisers, and that third-party exports are not described as automatic filing. Confirm that payment files and feeds are not described as settlement and that no universal bank, provider, or payroll coverage is implied. Review the separate rounding and residual controls.
Finally, verify that Odoo subscriptions and third-party charges are separated, the proposal currency is stated, package totals are established after discovery, and scheduling language matches actual operating capacity. The signed blueprint, assumptions, and acceptance matrix form the baseline for any later phase or change request. Reviewed 2026-11-06.
Request a USD proposal grounded in your actual scope
Share entity and branch counts, current systems, user roles, history requirements, states, providers, banks, hardware and client availability. We will identify what discovery must prove before a phase fee can be fixed.
Get in Touch
Buhaira Corniche, 43132 Sharjah,
United Arab Emirates