Sage 50 and Basware integration

What moves between them

The main flow runs from Basware down into Sage 50. When an invoice in Basware is coded, approved, and waiting for transfer, ml-connector reads it and creates the matching purchase invoice (bill) in Sage 50 through the SDK, preserving the supplier, amounts, and GL coding lines. Master data runs the other way: Sage 50 vendors, GL accounts, and cost centers are imported into Basware so the coding panel only offers accounts that exist in the ledger. After Sage 50 records the payment against a bill, ml-connector calls Basware's paymentResponses endpoint to confirm it. Basware initiates no payments and holds no general ledger of its own, so it stays the AP front-end while Sage 50 stays the book of record. Reads run on a polling schedule, typically every few minutes to hourly.

How ml-connector handles it

ml-connector runs a lightweight agent in a Windows desktop session beside the Sage 50 install (a scheduled task or tray app, since the SDK cannot run as a headless service) and talks to Basware's cloud API over HTTPS. Both credential sets are stored encrypted: the agent opens the Sage company with a dedicated Sage username and password, and the cloud side exchanges the Basware client ID and secret for a bearer token, requesting a fresh token when one expires because there is no refresh token. The customer's Basware region is set at configuration so the right base URL and token endpoint are used. When ml-connector subscribes to Basware webhooks it answers the ConnectionTest with HTTP 200, and it verifies every payload's HMAC-SHA256 signature, parsing the body as UTF-8 first. Basware paging uses a continuation token returned in a response header and sent back as a request header, which ml-connector forwards even across redirects so the Authorization header is not dropped. Sage 50 itself is polled, since it has no events, and the SDK takes an exclusive lock on the company file, so the agent uses a dedicated Sage user and avoids running while someone is logged into Sage interactively. Sage has no idempotency keys, so before creating a bill ml-connector checks for an existing invoice with the same reference and stores the Sage-assigned ID in its mapping table. On the Basware side, an unchanged record is silently skipped on import, so a field must differ to retrigger a vendor or coding update. Failed calls back off and retry, and every record carries a full audit trail and can be replayed.

A real-world example

A regional construction and facilities firm of about 250 staff runs Sage 50 in its back office for the general ledger and supplier payments, and adopts Basware to get invoices off paper and into a coded, approved digital workflow. Before the integration, an AP clerk opened each approved invoice in Basware and rekeyed it into Sage 50 as a bill, copying the supplier, amount, and account code by hand, then later went back into Basware to mark which invoices had been paid. With Sage 50 and Basware connected, approved invoices post into Sage 50 automatically with their coding intact, the supplier list and chart of accounts in Basware match the ledger so coders pick valid accounts, and payment status flows back without a second login. The double entry disappears and the two systems stop drifting apart.

What you can do

• •Post approved, coded Basware invoices into Sage 50 as purchase invoices through the local SDK, with no re-keying.
• •Push Sage 50 vendors, GL accounts, and cost centers up to Basware so invoices are coded only to valid accounts.
• •Confirm payment status back to Basware after Sage 50 records the payment, keeping the AP workflow current.
• •Bridge Basware OAuth2 bearer tokens to the local Sage 50 username and password, and pin the correct Basware region.
• •Run a Windows agent that polls Sage 50 on a schedule and handles Basware webhooks, with retries and a full audit trail.

Questions

Which direction does data move between Sage 50 and Basware?

The main flow is Basware into Sage 50: approved, coded invoices become purchase invoices in Sage 50. Vendor and GL master data moves the other way, from Sage 50 up to Basware, so coding lands on real accounts. After Sage 50 records a payment, ml-connector confirms it back to Basware, which initiates no payments of its own.

Why does Sage 50 need a local agent instead of a cloud connection?

Sage 50 is desktop software with no cloud REST API and no webhooks. Its only supported integration surface is a local SDK that must run in a Windows desktop session on the machine where Sage 50 is installed. ml-connector therefore runs a small agent next to Sage 50 and syncs to Basware over HTTPS, polling Sage 50 on a schedule because it has no events to push.

How does the integration handle Basware OAuth2 tokens and webhook security?

ml-connector exchanges the Basware client ID and secret for a bearer token and requests a new one when it expires, since the client credentials flow has no refresh token. The customer's region is set so the correct base URL is used. Every Basware webhook is verified against its HMAC-SHA256 signature in the X-BWAPI-Signature-256 header, with the body read as UTF-8 before the hash is computed.