Wave Accounting and IBM Sterling integration

What moves between them

Wave invoices and payments flow from Wave into Sterling as EDI documents. ml-connector receives Wave webhook events (invoice.created, invoice.updated, invoice.paid, payment.created), translates them into EDI format (ANSI X12 810 for invoices and 820 for payments), and posts them to Sterling trading partner mailboxes on demand. Customer records from Wave are mapped to Sterling trading partners so the correct partner receives the EDI documents. Inbound EDI documents detected in Sterling mailboxes (via polling) are extracted, parsed, and recorded as Wave transactions to keep Wave's transaction ledger synchronized with trading partner activity. The main flow is Wave invoice and payment events -> Sterling EDI documents -> trading partners; inbound EDI from partners flows back to Wave as transactions.

How ml-connector handles it

ml-connector stores Wave OAuth credentials and refreshes the access token every 90 minutes before expiry (or on 401 response). It listens for Wave webhooks on a public HTTPS endpoint, verifies each webhook signature using the HMAC-SHA256 algorithm and the configured shared secret, and rejects malformed or replay signatures with a 401 response. For each incoming invoice or payment, ml-connector looks up the Wave customer ID in a mapping table to find the corresponding Sterling trading partner, constructs an ANSI X12 EDI document (810 for invoices, 820 for payments), and POSTs it to Sterling's mailbox creation endpoint using the Sterling instance URL, port, and HTTP Basic credentials. Because Sterling has no outbound webhooks, ml-connector polls the Sterling mailbox every 3 minutes, extracts each new message payload, detects its EDI message type (810 invoice, 820 payment, 810 credit memo), parses it into wave transaction fields (date, amount, account, memo), and creates or updates the corresponding Wave transaction via the GraphQL API. Wave webhooks require a return of HTTP 200 within seconds, so ml-connector acknowledges the webhook immediately and enqueues the Sterling POST in the background. Sterling's instance URL and port vary per customer deployment, so they are stored in the connection configuration alongside HTTP Basic username and password. Rate limits are not published by either platform; ml-connector implements exponential backoff with a 1-minute ceiling and tracks mailbox polling timestamps to avoid duplicate extractions. Both Wave access tokens and Sterling messages carry a full audit trail for replay and troubleshooting.

A real-world example

A small manufacturing business uses Wave Accounting for invoicing and general ledger, and ships products to three regional distributors. Before the integration, Wave invoices were printed and mailed, and inbound distributor payment advice arrived via email and required manual entry into Wave. With Wave and Sterling connected, each new Wave invoice is automatically translated into an ANSI X12 810 EDI document and routed to the distributor's mailbox within Sterling. When distributors return payment advice as EDI 820 remittance documents, Sterling polls and extracts them, and ml-connector records each as a Wave transaction against the correct customer and GL account. Month-end reconciliation now starts with distributor payments already recorded in Wave, eliminating manual re-keying and reducing cash application delays.

What you can do

• •Translate Wave invoices and payments into ANSI X12 EDI format (810, 820) and route them to trading partners through Sterling mailboxes.
• •Map Wave customers to Sterling trading partners so EDI documents reach the correct destination.
• •Receive and parse inbound EDI remittance (820) and invoice documents from Sterling mailboxes and record them as Wave transactions.
• •Authenticate Wave with OAuth 2.0 refresh tokens and Sterling with HTTP Basic credentials, handling token expiry and rate limit retries.
• •Poll Sterling mailboxes on a schedule to detect and extract new EDI documents while maintaining a complete audit trail for every record.

Questions

What EDI message types does the integration support?

ml-connector translates Wave invoices into ANSI X12 810 (invoice) and 820 (payment/remittance) EDI documents. Inbound EDI documents parsed from Sterling mailboxes include 810 (invoice), 820 (payment), and 810 credit memos. Other EDI types (POs, ASNs, 997 ACKs) are not handled in the base integration but can be added as custom extensions.

How does the integration handle Wave's webhook signature verification and Sterling's lack of webhooks?

Wave webhooks are verified using HMAC-SHA256 with the x-wave-signature header and a 5-minute replay window; ml-connector rejects any signature that does not match. Because Sterling publishes no outbound webhooks, ml-connector polls Sterling's mailbox API every 3 minutes to detect new EDI documents, extract their payloads, and record them in Wave. This polling window keeps transactions synchronized while respecting Sterling's pull-only architecture.

What happens if the Wave OAuth token expires or Sterling is unreachable?

Wave access tokens expire every 2 hours, but ml-connector refreshes them proactively every 90 minutes before expiry. If Sterling is unreachable or returns an HTTP error, ml-connector retries with exponential backoff (capping at 1 minute) and enqueues the message for replay. Every transaction attempt is logged in the audit trail so it can be manually replayed if needed.