For Odoo distributors

SideQuest for Odoo Beta

The same PO automation our QuickBooks Online customers use — now reading inbound customer POs from Gmail and drafting Quotations directly in Odoo. Currently in private beta with a waitlist.

What "Beta" means here

The connector is built and runs end-to-end on a live Odoo 17 sandbox: parses real PO emails, matches lines against your catalog, stages a local draft for review, submits as a Quotation, and learns customer part-number mappings over time. What it hasn't done yet: ship to a paying customer. We're recruiting one external tester before opening signup. Join the waitlist and we'll add you to the first batch when the gate opens.

How it works

Step 1

PO arrives in Gmail

Customer emails you a PO. SideQuest reads the labeled email — PDF, scan, photo, or plain text in the body.

Step 2

Lines match the Odoo catalog

A 5-step cascade matches every line to a product in your Odoo: exact SKU, learned cross-reference, partial, description, fuzzy. Unmatched lines flag for review.

Step 3

Draft Quotation, human review

SideQuest builds a local draft. You see what matched, what didn't, and any price variance. Nothing hits Odoo until you approve.

Step 4

Submit to Odoo

One command writes the draft as a real Quotation (sale.order) in your Odoo, with tax computed server-side. The cross-reference learns every customer part you assigned.

What's live, and what isn't

Live and validated

  • Read paths: products, customers, open invoices, recent quotations
  • Write paths: create / confirm / discard Quotations
  • Gmail ingestion: real OAuth, gmail.modify scope (never sends)
  • PDF + scan + plain-text PO parsing
  • Five-step match cascade against the live Odoo catalog
  • Local draft store, human-review gate, no auto-submit
  • Cross-reference flywheel — auto-learns customer SKUs on submit
  • Insights: catalog audit, pricing intelligence, customer health
  • Multi-period dashboard (HTML, offline)
  • Doctor self-check CLI (12 PASS/FAIL/WARN checks across Odoo + Gmail + stores)
  • Usage reporting to control plane (boot flush + 30-min auto-flush)
  • License system — separate Odoo tier in the control plane, admin license-mint endpoint
  • Operator productivity (Phase 7): review-queue report, price-variance check, outlier-line scan, bulk-submit-clean (env-gated), bulk-discard-drafts (dry-run default)
  • 66 unit tests green, Phases 1-7 validated live end-to-end on Odoo 17

Not in beta yet

  • Hard self-test across a full week of real-shaped POs (in progress — June 11 session staged 10 POs cleanly, matcher proven against 85-product catalog, 2 P1 bugs filed below)
  • P1 — Parser column mapping: on PDFs with both a Part Number column AND a Description column, the parser reads Description as the customer identifier and ignores Part Number. Lines still resolve via description matching, but the cross-reference flywheel can't accumulate (customer_part → internal_sku) rules from those POs. Same SKU-column-allowlist logic that landed in the QBO parser at v0.15.8 needs to be ported.
  • P1 — propose_estimate doesn't dedup by message_id: calling the tool against a Gmail message that already has a draft creates a second draft instead of returning the existing one. The fix exists in drafts.find_by_message_id (used by process_overnight_queue); it just needs to be wired into the propose_estimate code path too.
  • Twelve parity reporting tools as queryable Claude Desktop commands — top customers, top items, time saved, match quality by customer, etc. The data already renders in the offline dashboard; the per-tool Claude Desktop queries are the gap.
  • Auto-submit-if-clean (QBO has this — Odoo will follow, opt-in per customer, behind the SIDEQUEST_AUTOSUBMIT env gate)
  • Auto-label-unprocessed Gmail batch labeling
  • AR-followup sweep (QBO has this — Odoo equivalent queued)
  • OCR rescue for the hardest scans (Azure Document Intelligence)
  • Multi-attachment routing — picking the right PDF when an email has three attached
  • External-tester signoff (the release gate item)
  • Odoo App Store listing

Live proof from a real test session

Captures from a test session on June 11, 2026. Real Gmail inbox → real PDF parser → real Odoo 17 sandbox, end-to-end. Nothing posed.

Gmail inbox showing 10 purchase order emails with the purchase-orders label and PDF attachments
1. The input: 10 PO emails sitting in Gmail under the purchase-orders label. Each carries a PDF attachment. The connector reads emails labeled this way — nothing else gets touched.
Healthcare purchase order PDF — Prime Health Products, PO-664730, with line items
2a. One template: Healthcare PO PDF (PO-664730 from Prime Health Products). The parser extracted PO number, every line, quantities, prices, and totals that reconcile to the document header.
Industrial purchase order PDF — Industrial Pipe and Valve, PO-449319, with line items
2b. A different template: Industrial PO PDF (PO-449319 from Industrial Pipe & Valve). Different header (“SUPPLY ORDER” vs “PROCUREMENT REQUEST”), different layout, same clean extraction.
Odoo Inventory Products list view showing 85 products across multiple verticals
3. The catalog: Odoo Inventory → Products view. 85 products seeded across 9 verticals (MRO, Healthcare, Fasteners, Automotive, Industrial, Electrical, Bearings, Safety, Distribution). What the matcher cascade runs against.
Odoo Sales Quotations list showing 13 quotations created by SideQuest
4. The output: Odoo Sales → Quotations list. Real sale.order rows the connector wrote — draft state, awaiting operator confirmation. Tax computed by Odoo server-side, never by us.

Result: 10 PDFs parsed cleanly, 94 lines extracted with totals that reconcile to header, $223,536 in total pipeline staged as local drafts for review. Match rate jumped from 0/94 (3-product sandbox) to a working baseline once the catalog was seeded to real-shape size. The full operator queue → review → submit cycle ran against live Odoo without intervention. Full technical writeup →

Who it's for

Wholesale and industrial distributors running Odoo Community or Enterprise 16+, processing inbound customer POs by email. If your team retypes line items into sale.order forms today — plumbing, electrical, HVAC, fasteners, JanSan, MRO, foodservice, auto parts, building materials — this is the shape of problem we built for.

Architecture decisions worth knowing

The Odoo connector is the QuickBooks Online connector's twin: same five-step matcher, same draft-for-review gate, same local-first data posture. Customer data never leaves the operator's machine. We talk to Odoo over XML-RPC using a per-user API key. Tax is computed by Odoo server-side, never by us. The whole thing runs as a Claude Desktop MCP connector — no SaaS dashboard to log into, no cloud database holding your PO contents.

The shared core is vendored at lockstep with the QBO connector so behavior stays consistent. When we fix a parser bug for QuickBooks, Odoo gets it too. The vendoring ledger is part of the repo for anyone who wants to audit drift.

Pricing (intent)

Free during beta. At launch, pricing will mirror our QuickBooks Online connector tiers: 25 POs/month free, then Solo ($29), Growth ($99), or Scale ($299) based on monthly PO volume. Above 3,500 POs/month is custom. No price change for QBO customers — we're matching, not raising.

Join the Odoo beta waitlist

One external tester is going first; you'd be in the next batch. Email us and tell us what you sell, how many POs/month you handle, and which Odoo version you're on.

Email [email protected]

Honest read: why beta, why now

The connector works. We've run real POs from a real Gmail account through it into a real Odoo sandbox, end-to-end, and watched it learn cross-references over multiple sessions. What we haven't done yet is put it in front of an outside operator and watch them break it — that's the next step. Our release gate requires both an external tester signoff and our own before anything goes public. We're not skipping that step to chase a launch date.

SideQuest Automation · sidequestautomation.com
Questions? Send a brief