Odoo and Tipalti integration

What moves between them

Purchase orders flow from Odoo into Tipalti for invoice matching and approval. Approved Tipalti invoices and payment records flow back into Odoo, where ml-connector maps them to the correct vendors and GL accounts for posting in the general ledger. Supplier reference data and GL account dimensions are kept in sync bidirectionally so that invoice line allocations land on valid Odoo accounts and cost centers. Odoo is the source of truth for purchase documents, while Tipalti is the source of truth for payment status and compliance.

How ml-connector handles it

ml-connector stores encrypted API keys for both systems and presents the correct authentication scheme on each request: API key with Bearer token for Odoo JSON-2, and HMAC-SHA256 signature for Tipalti SOAP. It polls Odoo using the write_date timestamp filter to detect new or changed purchase orders since the last run, transforms each PO into Tipalti's invoice schema, and validates that the vendor and GL account exist in both systems before pushing. It then polls Tipalti for invoice and payment status changes, maps approved invoices back to their source POs, and creates account.move records in Odoo's general ledger with the correct dimensions. Because Odoo does not offer webhooks, the sync runs on a fixed schedule tied to your payment cycle, defaulting to daily with backoff on validation errors. Every PO and invoice carries a deduplication key so re-runs do not create duplicates.

A real-world example

A mid-sized manufacturing company runs Odoo Online for procurement and accounting, and uses Tipalti to manage payments to hundreds of global suppliers including international vendors subject to tax compliance. Before the integration, purchase orders entered in Odoo were manually exported and re-entered into Tipalti, invoices were matched and approved in Tipalti, and then the approved invoices had to be re-keyed into Odoo's general ledger for month-end reconciliation. With Odoo and Tipalti connected, each new purchase order flows automatically into Tipalti's workflow, approved invoices and payment records flow back into Odoo for GL posting, and the accounts payable process runs end to end without re-entry. The finance team can now see payment status in Odoo and focus on reconciliation instead of data transfer.

What you can do

• •Sync Odoo purchase orders into Tipalti for invoice matching and approval, with validation that vendors and GL accounts exist in both systems.
• •Receive approved Tipalti invoices and payment records back into Odoo and post them to the general ledger with the correct vendor and GL account dimensions.
• •Map Tipalti payees to Odoo vendor records and keep supplier reference data in sync across both systems.
• •Poll Odoo and Tipalti on a schedule tied to your payment cycle, with deduplication keys to prevent duplicate invoices and payments from re-runs.
• •Store encrypted API keys and present the correct authentication scheme for each system: Odoo API key and Tipalti HMAC-SHA256 signature.

Questions

Which direction does data move between Odoo and Tipalti?

Purchase orders flow from Odoo into Tipalti for invoice matching and approval. Approved invoices and payment records flow back from Tipalti into Odoo for general ledger posting. Supplier and GL account reference data are kept in sync bidirectionally so that every invoice line allocates to a valid account in both systems.

How does the integration handle Odoo's lack of webhooks?

ml-connector polls Odoo on a schedule tied to your payment cycle, typically daily, using the write_date timestamp filter to detect new or changed purchase orders since the last run. This pull-based approach is production-grade and avoids the unreliability of Odoo's experimental webhook system.

What happens if an Odoo purchase order cannot be posted to Tipalti?

ml-connector validates that the vendor exists in Tipalti and that the GL account exists in Odoo before pushing the PO. If validation fails, the record is flagged in the audit log with the reason, and the operator is alerted. The integration does not proceed until the missing vendor or account is created in both systems.