Odoo and Avalara integration

What moves between them

The main flow is from Odoo into Avalara. When an invoice or purchase order is posted in Odoo, ml-connector reads the invoice lines, submits the transaction to Avalara with customer location, product codes, and amount, and Avalara returns the calculated tax by jurisdiction and line item. ml-connector then posts the tax amounts back into Odoo as tax GL entries and line-item tax adjustments, mapped to your Odoo GL accounts by tax code and company. Reference data such as customer addresses and product tax codes are synced from Odoo to Avalara so tax calculations are accurate on first attempt.

How ml-connector handles it

ml-connector polls Odoo's account.move table on a schedule tied to your invoice post cycle, filtering on write_date to capture only new or changed records since the last run. For each invoice, it extracts the customer address, invoice lines, and product tax codes from Odoo, then submits a CreateTransaction request to Avalara with those details and the document code as the Odoo invoice number for idempotency. Avalara returns the calculated tax per line and jurisdiction. ml-connector stores the Avalara transaction ID encrypted and posts the tax amounts back into Odoo as new GL journal entries allocated to your tax GL accounts. Because Avalara commits transactions synchronously and does not push updates, ml-connector polls ListTransactionsByCompany periodically to verify commits and catch any reconciliation gaps. Both credential sets are stored encrypted, and every record carries an audit trail for downstream replay if a posting fails.

A real-world example

A mid-sized consumer goods distributor runs Odoo for sales, purchasing, and general ledger across three states and two Canadian provinces. Before the integration, the accounting team calculated sales tax manually after each invoice post, checking Avalara's lookup tables for current jurisdictional rates, then hand-entered the tax GL entries each week before closing the books. Mistakes in tax allocation caused reconciliation delays and compliance risk. With Odoo and Avalara connected, every invoice's tax is calculated and posted automatically, accurate to the customer's location and current rates, and the GL is ready for close without re-keying or lookups.

What you can do

• •Calculate real-time sales and use tax on Odoo invoices and purchase orders using Avalara's jurisdiction-specific rate tables.
• •Post tax GL entries directly into Odoo's general ledger, allocated to the correct tax liability and deferred tax accounts.
• •Validate customer and supplier addresses in Avalara before tax calculation to prevent failures from incomplete location data.
• •Sync product tax codes from Odoo to Avalara so invoices are classified correctly by product category and tax treatment.
• •Reconcile tax transactions against Avalara's records periodically, with full audit trail and replay capability on failed GL postings.

Questions

Does Avalara push tax notifications back to Odoo, or does ml-connector poll?

Avalara is pull-only: it does not push callbacks or webhooks. ml-connector polls Odoo on a schedule tied to your invoice post cycle, reads new invoices, submits them to Avalara for tax calculation, and immediately posts the results. Periodically, ml-connector also polls Avalara's transaction history to verify commits and catch any gaps between Odoo and Avalara.

What happens if a customer address in Odoo is incomplete or invalid?

Avalara requires valid addresses for tax calculation. ml-connector validates each customer address against Avalara's /addresses/resolve endpoint before calculating tax. If an address cannot be resolved, ml-connector flags the record in the audit trail and pauses posting until the address is corrected in Odoo.

How does ml-connector handle Avalara's idempotency key requirement?

Avalara uses the document code as an idempotency key: reusing the same code returns a DocumentCodeConflict error. ml-connector uses each Odoo invoice number as the document code and stores the Avalara transaction ID encrypted so that retries or replays use the same Avalara transaction rather than attempting to recreate it.