Skip to content

Accountify platform product requirements

Attribute Value
Document version 0.2.0-draft
Status Draft for product, accounting, security, and engineering review
Last updated July 3, 2026
Product boundary Multi-tenant accounting operations platform for Accountify staff and clients
Initial scale 300 client Odoo databases plus one Accountify HQ Odoo database
First release slices Bank reconciliation, Accountify billing, German B2B e-invoicing readiness, bounded Shopify ecommerce pilot
Product authority This PRD
Technical authority Accountify platform specification v0.4
Ecommerce authority Ecommerce contract registry

This PRD defines why Accountify is being built, who it serves, what the product must deliver, and how success is measured. It does not repeat database columns, API payloads, Odoo fields, accounting equations, or failure-handling algorithms already governed by the linked technical contracts.

1. Executive summary

Accountify is a multi-tenant accounting operations platform that gives Accountify staff and clients one controlled workspace for reporting, document exchange, accounting work queues, review, approval, and integration health. It coordinates work across up to 300 client Odoo 19 Online databases, Accountify's self-hosted Odoo 19 Enterprise database, and approved commerce sources without replacing Odoo as the legal accounting system of record.

The product addresses four initial workflows:

  1. Prepare, review, execute, and verify supported client bank reconciliations.
  2. Calculate Accountify service billing, approve it under separation of duties, and export verified invoices to Accountify HQ Odoo.
  3. Ingest a bounded Shopify accounting profile, transform it into reproducible accounting evidence, post approved commands to client Odoo, and reconcile settlements through payouts, bank evidence, and Odoo clearing accounts.
  4. Make each in-scope German client company ready to receive structured B2B E-Rechnungen and, after tenant-specific proof, issue and monitor them through Odoo.

Accountify succeeds only when it reduces fragmented manual work while preserving accounting correctness, tenant isolation, explainability, approval controls, and authoritative Odoo readback. A successful API response is not proof of an accounting outcome.

2. Business problem

Accountify currently needs to operate across many independent Odoo databases and external data sources. Without a shared control plane, staff must switch systems, inspect inconsistent client configurations, move evidence manually, track approvals outside the accounting workflow, and build cross-client reporting from delayed or incomplete information.

This creates material business risks:

  • Repetitive work limits the number of clients one accounting team can serve.
  • Inconsistent tenant configuration makes automation unreliable.
  • Manual handoffs weaken evidence, accountability, and separation of duties.
  • Timeouts and retries against Odoo can create ambiguous or duplicate mutations.
  • Source, settlement, payout, bank, and ledger differences can remain unresolved until close.
  • Live fan-out to client databases cannot support responsive cross-client operations at scale.
  • Clients lack a consistent view of outstanding work, documents, billing evidence, and data freshness.
  • E-invoice readiness, delivery state, and structured-document evidence can vary silently across client databases even though German receiving obligations already apply.

The product must convert these fragmented activities into versioned, tenant-scoped workflows with explicit ownership, review state, evidence, and safe recovery.

3. Product vision and principles

Vision: Accountify staff should manage routine accounting operations from one trustworthy workspace, while clients retain Odoo as their accounting system of record and can understand the status and evidence behind every supported workflow.

Product decisions follow these principles:

  • Odoo remains authoritative. Accountify orchestrates and verifies; it does not become a second ledger.
  • Fail closed. Unsupported tax, mapping, currency, inventory, or accounting cases become explicit exceptions.
  • Evidence before success. Mutations complete only after authoritative readback proves the expected result.
  • Tenant isolation by construction. Every row, event, job, cache key, export, and object reference is tenant-scoped.
  • Human control where judgment matters. Accounting-sensitive changes preserve review and separation of duties.
  • Explainability over invisible automation. Users can see source evidence, policy and mapping versions, freshness, controls, and operation status.
  • Rebuildable reporting. Warehouse marts serve reporting but never control transactional workflow.
  • Automation is earned. Ordinary cases may be automated only after controlled pilot evidence proves them.

4. Goals, KPIs, and measurement

Product goals

  1. Reduce staff effort and context switching for supported accounting workflows.
  2. Improve accounting-operation reliability and traceability across client Odoo databases.
  3. Give staff and clients timely, understandable workflow and reporting status.
  4. Scale shared operations to 300 tenants without tenant-specific application deployments.
  5. Preserve security, accounting control, and data-governance standards while increasing automation.

Primary KPIs

No production baseline exists yet. Percentage and efficiency targets below are provisional pilot targets; zero-tolerance accounting and security guardrails are release invariants.

KPI Definition Provisional target Decision supported Source
Verified workflow completion rate Supported operations reaching confirmed readback divided by supported operations reaching a terminal state At least 99% for ordinary pilot cases; 100% classified Whether a workflow is reliable enough to expand Operations, attempts, readbacks
Staff handling-time reduction Median active staff minutes per completed supported workflow compared with the measured shadow-run baseline Establish baseline in shadow; reduce by at least 30% within 90 days of controlled use Whether the product creates operational value Work-item events and product telemetry
On-time accounting completion Tenant-period workflows completed by the agreed due date with required evidence and controls Establish pilot baseline; target at least 95% after close management launches Whether Accountify improves delivery predictability Close, work, exception, freshness records

Drivers and guardrails

Type Metric Definition or target
Driver Tenant activation Time from approved onboarding to healthy Odoo/source capability profile and first verified workflow
Driver Ordinary-case completion without repair Confirmed supported operations requiring no manual repair divided by confirmed supported operations
Driver Exception backlog age Open exceptions by class, owner, median age, p95 age, and overdue count
Driver Data-product freshness Percentage of source projections and operational marts within their contract target
Driver E-invoicing readiness In-scope client companies with current receive/issue capability evidence divided by in-scope client companies
Guardrail Cross-tenant exposure Zero successful isolation probes or unauthorized disclosures
Guardrail Duplicate Odoo mutation Zero duplicate confirmed mutations for one business operation
Guardrail Unexplained accounting difference Zero unexplained write-offs or hidden source-to-ledger/control differences
Guardrail Stale-data transparency 100% of stale or incomplete reports expose status and reason

Measurement plan

  • Instrument durable domain events and work-item state changes; do not infer completion from page views.
  • Freeze metric definitions and versions before the shadow period.
  • Capture current manual handling time for representative workflows before setting final efficiency targets.
  • Review operational KPIs weekly during pilot and outcome KPIs monthly.
  • Segment by tenant, workflow, operation type, source connection, and automation policy without exposing cross-tenant data.
  • Treat missing telemetry, invalid controls, or unclassified outcomes as incomplete rather than successful.

5. Target users

Persona Primary need Product roles Typical decisions
Client finance stakeholder Understand accounting status, reports, billing evidence, and outstanding requests Client viewer Review status and evidence
Client contributor Provide documents and answer structured requests Client contributor Upload or respond; no accounting approval
Accountify accountant Complete assigned accounting work efficiently with reliable evidence Staff preparer, commerce preparer, billing preparer Prepare candidates, mappings, drafts, and exceptions
Accountify reviewer Review and approve accounting-sensitive work independently Staff reviewer, commerce approver, billing approver Approve, reject, or return work
Data operations specialist Keep ingestion, capabilities, and reporting data healthy Data operations Scan, backfill, refresh, and repair non-accounting data products
Integration operator Maintain Odoo/source connectivity and recover failures safely Operations admin Rotate credentials, deploy wrappers, verify unknown outcomes
Platform administrator Configure the platform and perform controlled emergency access Platform admin Provision, configure, and audited break-glass administration
Product and compliance owner Decide scope, policy, risk acceptance, and rollout Outside routine runtime roles Approve product, accounting, security, and privacy changes

Assignment limits staff access in addition to role. A preparer or last material editor cannot approve the same accounting-sensitive item.

6. User flows

Common controlled workflow

flowchart LR Detect[Detect work or exception] Prepare[Prepare with evidence] Review[Independent review] Accept[Durably accept command] Execute[Execute in Odoo] Readback[Authoritative readback] Complete[Complete and report] Repair[Verify or repair] Detect --> Prepare --> Review --> Accept --> Execute --> Readback Readback -->|Matched| Complete Readback -->|Unknown or mismatch| Repair Repair --> Readback

Core journeys

Journey Trigger User flow Successful outcome
Tenant onboarding Signed client and approved scope Create tenant, bind Odoo/source connections, assign users, scan capabilities, configure policies, validate clone Enabled capabilities have current evidence and approved owners
Bank reconciliation Unreconciled bank transaction appears Review ranked candidates, inspect fingerprint/evidence, prepare, independently approve, execute, verify residuals One confirmed reconciliation or explicit exception
Accountify billing Billing period becomes calculable Collect usage, calculate run, review adjustments, approve, export draft invoice to HQ Odoo, separately approve posting, synchronize payment state Verified HQ invoice and traceable billing evidence
Ecommerce accounting Shopify event or Airbyte record arrives Verify receipt, canonicalize, resolve mappings/policy, prepare and approve posting intent, execute in Odoo, read back, reconcile settlement/payout/bank Balanced source-to-ledger evidence or owned exception
Inbound E-Rechnung Odoo receives Peppol or another approved structured invoice Preserve/validate structured artifact, synchronize draft/status, deduplicate, route to AP workbench, review and post under AP controls Posted Odoo bill or explicit owned exception with intact structured evidence
Outbound E-Rechnung Posted customer invoice requires structured delivery Verify customer format/endpoint, generate and send in Odoo, synchronize XML/message/status evidence, resolve errors Odoo delivery evidence or explicit owned exception
Document request Workflow requires client evidence Create request, notify client, upload/version/scan document, review response, close request Required evidence is attributable and linked to work
Period close Accounting period enters close preparation Complete dependent tasks, resolve exceptions, refresh Odoo/mart evidence, independent review, close or reopen with reason Completed checklist with immutable evidence hash
Integration incident Health, freshness, drift, or unknown outcome breaches policy Contain, diagnose, verify, repair/replay where safe, reconcile controls, record evidence Service restored without duplicate mutation or hidden difference

7. Scope and feature list

First-release scope

Feature group Product capability Priority Current state
Identity and tenancy Login, tenant membership, assignment, role enforcement, step-up administration P0 Specified; not implemented
Connection management Odoo/source registry, credentials, companies, capabilities, health, drift P0 Specified; not implemented
Work management Tenant-scoped queues, ownership, due dates, review, evidence, exceptions P0 Specified; not implemented
Bank reconciliation Candidate review, guarded command, readback, recovery, audit P0 Specified; Odoo proof pending
Accountify billing Contracts, usage, calculation, approval, HQ export, posting, status synchronization P0 Specified; HQ module pending
Shopify ingestion Webhook and Airbyte receipt, raw evidence, canonicalization, completeness P0 pilot Specified; not implemented
Ecommerce posting Mapping, policy, posting intents, Odoo commands, readback, exceptions P0 pilot Specified; clone proof pending
Settlement reconciliation Fees, refunds, disputes, payouts, bank and Odoo clearing controls P0 pilot Specified; accounting sign-off pending
Reporting Operational health, finance marts, freshness, drill-through, exports P0 Initial post-Odoo reference artifacts only
Documents Requests, uploads, versions, scanning, access history P1 Specified; not implemented
Period close Checklists, dependencies, evidence, review, reopen, drift P1 Specified; not implemented
Operations Health, incidents, replay/repair, credential rotation, wrapper deployment P0 Specified; monitoring rules partially defined
Supplier invoice workbench Draft bill coding, review, attachments, purchase/receipt context P1 Workflow guide exists; product implementation pending
German B2B e-invoicing Per-company receive/issue readiness, structured intake, Odoo/Peppol status, evidence, exceptions P0 Runtime surface verified and implementation contract added; tenant fixtures pending

Explicit non-goals for the first release

  • Reimplement Odoo accounting engines or maintain a complete client-ledger replica.
  • Expose arbitrary Odoo models, methods, fields, domains, SQL, or context to users.
  • Claim unconditional exactly-once mutation for Odoo Online.
  • Automate unsupported tax, multi-currency, transfer, chargeback, write-off, gift-card, or marketplace cases.
  • Support Amazon, eBay, or additional posting profiles without separate admission contracts.
  • Use Accountify HQ Odoo as the cross-client warehouse.
  • Issue or transport client invoices from a parallel Accountify service when client Odoo is the approved legal invoice endpoint.
  • Add Stripe, OpenAI, Slack, or other unrelated integrations without an approved product requirement and data/security review.

8. UI and UX requirements

The first experience is an operational application, not a marketing site. It should optimize for repeated accounting work, scanning, comparison, evidence, and safe action.

UX principles

  • Show tenant, company, period, currency, data freshness, and workflow state wherever they affect interpretation.
  • Separate preparation from approval visually and behaviorally.
  • Explain why a candidate, mapping, policy, or operation is blocked.
  • Keep high-risk commands explicit; do not hide them behind generic save actions.
  • Preserve filters and queue position when users inspect and return from detail views.
  • Never display raw credentials, unsafe upstream errors, or another tenant's identifiers.
  • Expose stale, partial, unsupported, and unknown states; do not present them as successful.

Required product surfaces

Surface Primary users Required content Design status
Tenant portfolio and home Staff, operations Assigned tenants, health, deadlines, exception counts, freshness Wireframe required
Unified work queue Preparers, reviewers Ownership, workflow, priority, age, due date, review state Wireframe required
Bank reconciliation workbench Accounting staff Transaction, candidates, scoring evidence, fingerprint, residual preview, approval Existing behavior guide; product wireframe required
Ecommerce operations Commerce staff Source health, mapping exceptions, posting intents, operation/readback status Wireframe required
Settlement and payout workbench Commerce staff, reviewers Control equation, allocations, differences, bank/Odoo evidence Wireframe required
Billing runs Billing staff Frozen inputs, adjustments, totals, approvals, export/posting receipts Wireframe required
Client workspace Client users Reports, document requests, uploads, billing evidence, status Wireframe required
Period close Accounting staff, reviewers Checklist, dependencies, evidence, blockers, Odoo/mart freshness Wireframe required
Reports and exports Clients, staff Governed metrics, filters, completeness, lineage, export status API contract exists; wireframe required
Integration health Data operations, operations admins Connections, capabilities, drift, jobs, incidents, safe repair actions Wireframe required

Design deliverables before frontend implementation

  1. Information architecture and route map.
  2. Low-fidelity desktop flows for onboarding, work queue, reconciliation, ecommerce exceptions, billing, and close.
  3. Figma component library with states for loading, empty, stale, blocked, unknown, failed, and read-only access.
  4. Clickable prototype covering preparer/reviewer separation and timeout recovery.
  5. Responsive behavior for desktop and mobile client tasks.
  6. Accessibility review targeting WCAG 2.2 AA.

No approved Figma file or production wireframe is currently part of the repository.

9. Functional requirements

ID Requirement Acceptance summary
FR-001 The platform shall authenticate users through OAuth/OIDC and bind every request to server-resolved identity. Invalid or disabled identities cannot access tenant resources.
FR-002 The platform shall authorize by tenant membership, role, assignment, resource state, and separation-of-duties rules. Cross-tenant and self-approval negative tests pass.
FR-003 Administrators shall provision tenant-bound Odoo and source connections without exposing credentials to browsers. Connections resolve only from trusted registry records.
FR-004 Capabilities shall be evidenced, versioned, expire, and block workflows when required support is missing or stale. Unsupported workflows cannot be enabled.
FR-005 Staff shall manage work through tenant-scoped queues with ownership, state, priority, deadlines, evidence, and review history. Every transition is authorized and auditable.
FR-006 Clients shall view authorized status and provide requested documents through versioned, scanned, tenant-scoped storage. Upload, access, retention, and deletion tests pass.
FR-007 Every in-scope client company shall have separate, current German B2B e-invoice receive and issue capability evidence before either workflow is enabled. Installation, configuration, endpoint, format, ACL, fixture, retention, and drift gates pass per company.
FR-008 Accountify shall preserve and route inbound structured invoice evidence without silently replacing XML values with OCR or rendered values. Valid, invalid, duplicate, correction, and structured/rendered mismatch fixtures reach the expected AP state.
FR-009 Outbound e-invoice delivery shall occur through the approved Odoo route and complete only from authoritative XML and transport-status readback. Queued, delivered, error, delayed, and unknown outcomes are correctly classified without duplicate send.
FR-010 Accounting staff shall review supported reconciliation candidates and submit an idempotent approved command. Stale fingerprints and unsupported scenarios are rejected.
FR-011 Reconciliation shall be successful only after fresh Odoo readback verifies residual and reconcile evidence. Timeout-after-commit produces no duplicate confirmed mutation.
FR-020 Billing staff shall calculate reproducible billing runs from frozen contracts, pricing, usage, and evidence. Recalculation and correction create attributable revisions.
FR-021 HQ invoice export and posting shall require separate approvals and Odoo-side receipts. Concurrent replay creates one receipt and verified outcome.
FR-030 Shopify webhooks and Airbyte records shall converge through one idempotent tenant-attributed ingestion boundary. Duplicate and out-of-order delivery produces one canonical outcome.
FR-031 Canonical commerce shall preserve source identity, monetary precision, lineage, and independent lifecycle states. Golden fixtures reproduce the same canonical result.
FR-032 Mappings and accounting policies shall be effective-dated, versioned, approved, and frozen into posting intent. Missing or changed policy blocks execution.
FR-033 Ecommerce mutations shall use allowlisted business commands and authoritative Odoo readback. Clone tests cover create, post, pay, refund, return, and recovery.
FR-034 Settlements shall reconcile source components to provider payout, bank evidence, and Odoo clearing residual. Every difference is zero, tolerated by approved policy, or explicit exception.
FR-035 Refund, return, dispute, and inventory workflows shall preserve separate financial and physical state. Unsupported combinations fail closed.
FR-040 Reports shall query published tenant-scoped marts and expose freshness, completeness, metric version, and lineage. No report request calls a source or Odoo synchronously.
FR-041 Exports shall be asynchronous, attributable, content-hashed, access-controlled, and time-limited. Export audit and expiry tests pass.
FR-050 Operations users shall inspect health, incidents, jobs, unknown outcomes, drift, and safe recovery actions. Repair cannot bypass authorization or readback.
FR-060 Period close shall enforce checklist dependencies, current evidence, independent review, and controlled reopening. Completion and reopen evidence is immutable and attributable.
FR-070 Sensitive user, system, and integration actions shall produce append-only audit evidence. Audit records identify actor, tenant, action, reason, correlation, and result.

Detailed acceptance behavior is normative in the platform specification and ecommerce operations contract.

10. Non-functional requirements

ID Requirement Target or rule
NFR-001 Tenant isolation Forced PostgreSQL RLS or equivalent authorized serving boundary; zero successful cross-tenant probes
NFR-002 Mutation safety Durable operation before 202; idempotency, single-flight/fencing, bounded retry, mandatory readback
NFR-003 Security Managed secrets, TLS, egress allowlists, SSRF protection, redaction, step-up administration, least privilege
NFR-004 Privacy Data minimization, classification, approved retention, restriction/deletion, tenant offboarding, controlled non-production data
NFR-005 Availability Platform-only API target 99.9% monthly
NFR-006 Performance Platform API p95 below 500 ms; 90-day tenant dashboard p95 below 2 seconds; asynchronous exports
NFR-007 Freshness Contract-specific source, Odoo readback, and mart targets with visible stale state
NFR-008 Scale 300 tenants without tenant-specific deployments or permanently assigned workers
NFR-009 Recovery Tested backup/restore, cursor rebuild, outbox replay, worker crash recovery, and unknown-operation classification
NFR-010 Observability Tenant-safe metrics, logs, traces, correlation IDs, SLOs, alerts, and runbooks
NFR-011 Accessibility WCAG 2.2 AA target for staff and client workflows
NFR-012 Compatibility Versioned APIs/events; current and previous compatible version supported during rollout

11. System architecture

The first release is a modular monolith with separately scalable API, scheduler, and worker processes sharing one versioned codebase and PostgreSQL cluster.

flowchart LR Users[Clients and Accountify staff] Web[Web application] API[Platform API] DB[(PostgreSQL)] Queue[(Managed queue)] Workers[Shared workers] Files[(Object storage)] Secrets[Secrets manager] Sources[Shopify and Airbyte] ClientOdoo[Client Odoo Online] HQOdoo[Accountify HQ Odoo] Marts[(Warehouse marts)] Users --> Web --> API API --> DB API --> Files API --> Queue --> Workers Workers --> Secrets Sources --> Workers Workers --> ClientOdoo Workers --> HQOdoo DB --> Marts --> API

Component ownership and failure guarantees are defined in System context and ownership and Runtime and deployment profiles.

12. Database design

The conceptual product model is:

erDiagram TENANT ||--o{ MEMBERSHIP : authorizes TENANT ||--o{ CONNECTION : owns CONNECTION ||--o{ CAPABILITY : proves TENANT ||--o{ WORK_ITEM : organizes WORK_ITEM ||--o{ EVIDENCE : references TENANT ||--o{ OPERATION : accepts OPERATION ||--o{ ATTEMPT : executes OPERATION ||--o{ READBACK : verifies TENANT ||--o{ COMMERCE_AGGREGATE : canonicalizes COMMERCE_AGGREGATE ||--o{ POSTING_INTENT : proposes TENANT ||--o{ SETTLEMENT : reconciles TENANT ||--o{ BILLING_RUN : calculates TENANT ||--o{ CLOSE_PERIOD : controls TENANT ||--o{ AUDIT_EVENT : records READBACK ||--o{ WAREHOUSE_FACT : projects WAREHOUSE_FACT ||--o{ MART_PARTITION : aggregates

Normative tables, composite tenant foreign keys, RLS policies, operations, projections, ecommerce persistence, billing, documents, audit, close, and indexes are defined in Normative PostgreSQL design. The repository currently contains executable migrations only for the post-Odoo readback/outbox/warehouse slice; the complete foundation and domain migrations remain to be implemented.

13. API requirements

API group Purpose Machine-readable status
Identity and tenant context Session identity, memberships, assignments Pending
Reconciliation Bank transactions, candidates, reconciliation operations Documented; OpenAPI pending
Billing Contracts, runs, recalculation, approval, export, posting Documented; OpenAPI pending
Ecommerce operations Capabilities, ingestion runs, commerce resources, mappings, posting intents Documented; OpenAPI pending
Settlements and payouts Allocation, approval, posting, reconciliation Documented; OpenAPI pending
Reporting Sales, refunds, fees, settlements, inventory, posting health, freshness OpenAPI 3.1 pilot reference present
Platform operations Tenant health, scans, syncs, deployments, verification, incidents Documented; OpenAPI pending

All APIs use /api/v1, OAuth/OIDC identity, server-side tenant authorization, decimal money, UTC timestamps, cursor pagination, resource versions, safe errors, and idempotent asynchronous commands. See the HTTP API contract.

14. Authentication and authorization

  • Authentication uses an OAuth/OIDC identity provider; provider selection is an open architecture decision.
  • The browser never receives Odoo, Shopify, Airbyte, database, object-store, or webhook credentials.
  • Authorization combines tenant membership, staff assignment, role, resource state, and separation of duties.
  • Queued commands re-evaluate authorization at execution time.
  • Administrative and break-glass actions require step-up authentication, reason, time limit, and enhanced audit.
  • Runtime database roles cannot bypass RLS through table ownership.
  • The role matrix in Authorization and separation of duties is normative.

15. Integrations

Integration Role Release status
Client Odoo 19 Online Client accounting system of record Required; Studio wrapper and clone proof pending
Odoo electronic invoicing and Peppol Client-company E-Rechnung generation, receipt, structured evidence, and transport status Required for in-scope German companies; per-tenant production fixture proof pending
Accountify HQ Odoo 19 Enterprise Accountify CRM, billing invoices, receivables, corporate accounting Required; custom receipt module pending
Shopify Pilot commerce source Required for ecommerce pilot; capability fixture pending
Airbyte Scheduled replication, completeness, replay, backfill Required for ecommerce pilot; deployment pending
Odoo bank/accounting data Bank transactions, reconciliation, clearing and payment evidence Required through approved Odoo surface
OAuth/OIDC provider User authentication and step-up Provider decision pending
Secrets manager Integration credentials and rotation Provider decision pending
Object storage Documents, raw evidence, exports, large snapshots Provider decision pending
Managed job queue Asynchronous work and fair scheduling Provider decision pending
Observability platform Metrics, logs, traces, alerts Provider decision pending
Stripe, OpenAI, Slack No approved first-release requirement Out of scope until separately specified

16. Deployment and environments

The documentation portal is deployable to Cloudflare Pages under developers.accountify.solutions; that is not the application deployment architecture.

The product requires isolated development, staging, and production environments with:

  • separate identity clients, credentials, databases, queues, object storage, and encryption keys;
  • automated forward-only database migrations and rollback-of-release procedures;
  • representative non-production Odoo clones with sanitized fixtures;
  • CI gates for unit, database, contract, tenant-isolation, migration, security, and documentation tests;
  • staged rollout through shadow, clone, one-tenant pilot, cohort, and canary phases;
  • backup, restore, replay, and tenant-offboarding exercises before production expansion.

Hosting provider, region, infrastructure-as-code tooling, release orchestration, and data-residency policy remain open decisions.

17. Technology baseline

Layer Baseline Decision status
Application architecture Modular monolith; separately scalable API, scheduler, and workers Approved in platform specification
Web application TypeScript/React-class application Proposed; framework ADR required
Backend API and workers Single typed service codebase with strong PostgreSQL and Odoo support Language/framework decision pending
Operational database PostgreSQL with composite tenant keys and forced RLS Approved
Warehouse transformation dbt with PostgreSQL initially Pilot reference present
API/event contracts OpenAPI 3.1 and JSON Schema 2020-12 Approved
Queue Managed at-least-once delivery with leases/fencing and dead-letter handling Provider pending
Files S3-compatible managed object storage Provider pending
Authentication OAuth/OIDC with step-up support Provider pending
Telemetry OpenTelemetry-compatible traces plus Prometheus-compatible metrics Proposed; provider pending
Packaging and runtime Containerized services and reproducible dependency locks Proposed; deployment ADR required
Documentation MkDocs Material, Mermaid, generated Odoo runtime reference Implemented

Technology selections may not weaken tenant isolation, accounting evidence, idempotency, readback, recovery, or versioning requirements.

18. Delivery plan

Phase Outcome Exit evidence
P0 Product and contract proof Approved PRD, accounting policy, source/Odoo capability evidence, machine-readable contracts, fixtures Product/accounting/security approvals and reproducible fixtures
P1 Secure foundation Identity, tenancy, connections, operations, queue, audit, storage, RLS Automated cross-tenant and recovery tests
P2 Shadow ingestion and projections Shopify/Airbyte ingestion, canonical data, mappings, completeness, initial marts Seven consecutive controlled shadow days with reconciled totals
P3 Odoo clone workflows Reconciliation, billing, ecommerce posting, readback, unknown-outcome recovery Golden clone cases including timeout and concurrency
P4 Controlled tenant pilot One tenant, manual approval for every mutation, daily reconciliation No unresolved high-severity defect or unknown outcome over 24 hours
P5 Policy automation and client experience Proven ordinary-case automation, client workspace, documents, close Acceptance gates, runbook exercises, owner sign-off
P6 300-tenant readiness Automated onboarding, fair scheduling, load, restore, cohorts, canaries Scale and isolation report at representative volume

19. Prioritized backlog

Now: remove implementation blockers

  1. Assign product, accounting, security/privacy, Odoo, data-platform, and operations owners.
  2. Select one Shopify pilot store and representative client Odoo Online clone.
  3. Approve the order_invoice_v1 accounting policy and clearing-account design.
  4. Produce Shopify, Odoo, accounting, timeout, and correction fixtures.
  5. Complete foundation migrations, RLS tests, command OpenAPI, event schemas, source schemas, and policy schema.
  6. Inventory every in-scope German company and prove separate e-invoice receive/issue capability profiles with controlled fixtures.
  7. Choose identity, secrets, queue, object storage, observability, hosting, and application-stack providers through ADRs.
  8. Create the information architecture, Figma library, and critical-flow wireframes.

Next: build and prove the pilot

  1. Implement secure foundation services and CI integration environment.
  2. Implement Shopify webhook/Airbyte shadow ingestion and canonical controls.
  3. Implement mapping/policy workflows and exception queues.
  4. Implement Odoo Online adapter, Studio wrapper, readback, and unknown-outcome recovery.
  5. Implement HQ billing module and receipt contract.
  6. Complete settlement, payout, bank, clearing, refund, dispute, return, and inventory workflows.
  7. Complete governed marts, reporting service, operational UI, and audit surfaces.
  8. Implement e-invoice readiness/status projections, AP routing, exception queues, retention evidence, and monitored rollout.

Later: expand after evidence

  • Policy automation for proven ordinary cases.
  • Supplier invoice workbench and broader close/client operations.
  • Additional ecommerce sources and posting profiles.
  • Managed client Odoo execution profile.
  • Advanced portfolio capacity and profitability reporting.
  • Infrastructure specialization only when measured limits justify it.

20. Known gaps, risks, and open decisions

Gap or risk Impact Required resolution
No running product application Product workflows cannot be user-tested end to end Build foundation and first vertical slice
No approved UI designs Frontend scope and interaction details remain ambiguous Complete Figma and prototype review
No production KPI baseline Efficiency and adoption targets are provisional Instrument and measure shadow/manual baseline
Foundation/domain migrations incomplete Current SQL covers only post-Odoo warehouse boundary Implement and run complete migration suite
OpenAPI/event catalog incomplete Producers and consumers could drift Publish remaining immutable contracts before implementation
Odoo Online has weaker mutation guarantees than HQ Timeout outcomes can be ambiguous Single-flight, Studio wrapper proof, mandatory readback, repair workflow
HQ custom module not implemented Billing export cannot guarantee Odoo-side operation uniqueness Build and acceptance-test accountify_integration module
No representative clone/pilot evidence Model access, defaults, record rules, and workflows remain assumptions Execute capability and golden-flow suite
Accounting and governance approvals pending Production posting and data handling remain blocked Record versioned owner approvals
Infrastructure providers undecided Security, cost, operations, and implementation planning cannot be finalized Approve ADRs before foundation implementation
Full warehouse not implemented Reporting contract exceeds current facts and marts Add source, settlement, clearing, refund, fee, and inventory products
E-invoice tenant readiness is unproven Installed modules do not prove production endpoints, formats, routing, retention, or send/receive behavior Run separate receive/issue fixtures for every enabled company and monitor drift
Restore, load, and failure injection not executed 300-tenant and recovery claims remain unproven Run staged operational acceptance program

21. Release acceptance

The first production release is accepted only when:

  1. Product, accounting, security/privacy, and operations owners approve this PRD and applicable contracts.
  2. Every enabled workflow has current tenant-specific source and Odoo capability evidence.
  3. Cross-tenant tests pass across API, PostgreSQL, queue, object storage, cache, logs, search, and exports.
  4. Commands are durably accepted, idempotent, authorized at execution, and verified through readback.
  5. Required clone, timeout, duplicate, concurrency, failure-injection, restore, and runbook tests pass.
  6. Source, canonical, Odoo, settlement, bank, fact, and mart controls reconcile or expose approved exceptions.
  7. Reporting surfaces show freshness, completeness, metric version, and stale state.
  8. Pilot KPIs are instrumented and the manual/shadow baseline is recorded.
  9. One controlled tenant completes the agreed pilot period with manual approval and no unresolved high-severity defect.
  10. Production deployment, backup, restore, incident response, retention, and offboarding evidence is recorded.
  11. Every enabled German client company can receive a valid structured invoice and preserve its original structured part; every issue-enabled company passes controlled outbound delivery and status readback.

The detailed pilot and scale criteria in Platform testing and acceptance and Ecommerce operations and acceptance remain normative.

22. Requirements traceability

Product concern Authoritative detail
Product goals, personas, workflows, feature priority, KPIs, UX, roadmap This PRD
Platform ownership, tenancy, persistence, API, operations, authorization, resilience Platform specification
Odoo models, methods, fields, and access visible to the exporter Generated Odoo reference
Bank reconciliation behavior Bank reconciliation guide and platform reconciliation contract
Supplier invoice behavior Supplier invoice workbench
German B2B E-Rechnung readiness, Odoo fields, workflows, evidence, and rollout German B2B e-invoicing
Ecommerce scope and precedence Ecommerce contract registry
Ecommerce implementation status Post-Odoo implementation artifacts
Deployment of the documentation portal Repository DEPLOYMENT.md

23. Ownership and change control

Before approval, assign named owners for product, accounting, engineering, security/privacy, data platform, Odoo integration, operations, and UX. Each material change records requirement IDs, owner, decision date, affected contracts, compatibility, migration, test evidence, and rollout plan.

Changes to accounting treatment, tenant isolation, authorization, mutation guarantees, data retention, KPI definitions, or release gates require explicit approval from the accountable owner. Product examples and wireframes may clarify a contract but cannot weaken a technical or accounting invariant.