MYOB and Cleo integration

What moves between them

Purchase orders and bills flow from MYOB into Cleo on a polling schedule aligned to your procurement cycle. New or modified purchase orders in MYOB are fetched using OData LastModified filters and translated into EDI 850 format for Cleo; supplier invoices (bills) are similarly fetched and posted as EDI 810. Supplier payment records are synced for reconciliation visibility. Cleo translates these payloads into EDI files or native API calls for downstream trading partners. The integration runs read-only on the Cleo side, with updates flowing from MYOB outbound only.

How ml-connector handles it

ml-connector manages the two-factor auth requirement on the MYOB side by storing the OAuth Bearer token, API Key, and company file credentials (Base64 username:password) encrypted, and refreshing the token when it approaches expiry. On the Cleo side, it exchanges username and password for a short-lived Bearer token via OAuth2 password grant and includes that on every outbound call. Because MYOB has no webhooks, ml-connector polls the AccountRight API on a schedule you set, using OData $filter on the LastModified field to fetch only records changed since the last sync. Before posting a purchase order or invoice to Cleo, ml-connector stores the MYOB RowVersion to detect stale updates and prevent 409 conflicts on subsequent writes. EDI format mapping is driven by the purchase order and invoice line-item structure: MYOB items and descriptions map to EDI quantity, unit price, and line-total fields; supplier contact names and codes map to EDI buyer and seller identifiers. MYOB enforces a rate limit of 8 requests per second, so ml-connector backs off on HTTP 429 responses and queues retries with exponential jitter. Every record carries a full audit trail.

A real-world example

A mid-sized distributor in Sydney uses MYOB to manage AP and supplier relationships, and Cleo to distribute purchase orders and receipts across multiple warehouse sites and suppliers in the region. Before the integration, the procurement team exported purchase orders from MYOB as spreadsheets, re-keyed line items into Cleo for each supplier, and manually tracked which orders had been confirmed. With MYOB and Cleo connected, each new purchase order in MYOB appears in Cleo as an EDI 850 within seconds of creation. Suppliers confirm via Cleo; the confirmation flows back to MYOB for reconciliation. The manual data entry step is gone, lead times shorten, and the procurement team can focus on vendor relationships instead of spreadsheet logistics.

What you can do

• •Sync purchase orders from MYOB to Cleo as EDI 850 documents on a polling schedule you control.
• •Post supplier invoices and bills from MYOB into Cleo for downstream trading partner delivery.
• •Store and refresh MYOB OAuth2 tokens and company file credentials (x-myobapi-key, x-myobapi-cftoken) encrypted, and exchange Cleo credentials for short-lived Bearer tokens.
• •Track MYOB RowVersion on each record to detect stale updates and prevent 409 conflicts on subsequent writes.
• •Poll on a schedule tied to your procurement cycle, with retries on rate limits, a full audit trail, and error replay.

Questions

How does the integration handle MYOB's dual authentication requirement (OAuth token plus company file credentials)?

ml-connector stores all three required headers encrypted: the OAuth2 Bearer token (refreshed as it approaches 20-minute expiry), the API Key (x-myobapi-key), and the Base64-encoded company file credentials (x-myobapi-cftoken). All three are presented on every API call to the AccountRight Live API v2. If the company file credentials are stale, the API returns 401 and the sync stops with an alert.

Why does the integration poll instead of using webhooks?

MYOB AccountRight Live API v2 does not support webhooks or push notifications. ml-connector polls the AccountRight API on a schedule you set, using OData $filter on the LastModified field to fetch only records that have changed since the last sync. This minimizes API calls while keeping Cleo in sync with new or modified purchase orders and invoices.

What happens if a row is modified in MYOB between syncs?

ml-connector stores the MYOB RowVersion field for each record. On the next poll, if the record has changed and the stored RowVersion is stale, ml-connector detects this and prevents a 409 conflict by skipping the write, logging the issue, and alerting the user to manually resolve the divergence before retrying.