ml-connector
AcumaticaIBM Sterling

Acumatica and IBM Sterling integration

Acumatica runs finance, distribution, and operations. IBM Sterling B2B Integrator is the EDI backbone that translates and routes documents to and from your trading partners. Connecting the two lets Acumatica sales invoices and purchase orders leave as X12 EDI through IBM Sterling mailboxes, and lets the EDI your partners send arrive in Acumatica as bills, sales orders, and customer records. ml-connector handles the very different shapes on each side, since Acumatica speaks contract-based REST and IBM Sterling moves business data as EDI payloads inside mailbox messages, not native objects. It maps each Acumatica entity to its EDI transaction and moves the documents on a schedule you control.

How Acumatica works

Acumatica Cloud ERP exposes vendors, customers, AP bills, sales invoices, purchase orders, payments, and GL accounts through its Contract-Based REST API. Each instance has its own URL and a version-locked endpoint path, such as /entity/Default/24.200.001/, that must match the customer's ERP release or the call returns 404. All field values are wrapped in value objects, and entity names are case-sensitive. Authentication is OAuth 2.0 through the built-in OpenID Connect server, or a legacy login session cookie. Acumatica offers Push Notifications, but the common and reliable pattern is polling on LastModifiedDateTime with OData $top and $skip.

How IBM Sterling works

IBM Sterling B2B Integrator is EDI middleware, not a finance system, so it has no REST endpoint for an invoice or a purchase order. Its B2B REST API under /B2BAPIs/svc/ manages the platform itself: trading partners, mailboxes, mailbox messages, documents, workflows, schedules, and certificates. Business documents move through it as X12 EDI, where an 810 is an invoice, an 850 a purchase order, an 856 an advance ship notice, and an 820 a remittance. Authentication is HTTP Basic by default, with OAuth 2.0 client credentials on 6.2.2 and later, against a customer-run host and Liberty port rather than a shared cloud URL. The API has no outbound webhooks, so it is pull-based: drop a document in a mailbox to send, and poll mailbox messages to retrieve what arrived.

What moves between them

Documents move in both directions, mapped to their X12 transaction. Outbound from Acumatica, ml-connector reads new sales invoices and renders them as 810 documents, and reads purchase orders as 850 documents, then places each into the correct IBM Sterling mailbox for translation and routing to the trading partner. Inbound from IBM Sterling, it polls the mailbox messages for EDI a partner sent, extracts the payloads, and writes them into Acumatica: a partner 850 becomes a sales order, an 810 becomes an AP bill against the matching vendor, and 856 and 855 acknowledgments update the related documents. Cadence is a polling schedule you set, since the IBM Sterling REST API pushes nothing to an external endpoint on its own.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the IBM Sterling side it accepts the customer host and Liberty HTTPS port, since every instance is self-hosted with no shared URL, and authenticates with HTTP Basic using a dedicated non-super-user API account, since a super-user account is rejected by the REST API, or with OAuth2 client credentials on 6.2.2 and later. To send, it follows the platform's two-step contract: it POSTs the EDI payload to /documents to obtain a documentId, then creates a mailbox message that references that documentId, because the content cannot be inlined in the message POST. On the Acumatica side it accepts the full instance URL and the exact endpoint version per customer, since a mismatch returns 404, and wraps every field value in the required value object so writes do not fail with a 400. Each Acumatica entity is mapped to its EDI transaction before any document moves, so a sales invoice becomes a valid 810 and a purchase order a valid 850. Neither side has an idempotency key, so each outbound mailbox message is tagged and inbound messages are tracked by messageId, so a document is never sent or imported twice. IBM Sterling publishes no rate-limit headers and Acumatica returns 429 under load, so ml-connector backs off with jitter, and failed records are kept with a full audit trail for replay. Because the b2bAPI.jar component is a separate install that must be re-applied after fix packs, ml-connector surfaces a clear error if the REST API is missing rather than failing silently.

A real-world example

A mid-sized food distributor with around 250 employees runs Acumatica Cloud ERP for purchasing, inventory, and finance, and its largest grocery customers require EDI through an IBM Sterling B2B Integrator instance their parent company already runs on-premises. Before the integration, a clerk rekeyed each customer's 850 purchase order from a Sterling mailbox into Acumatica as a sales order by hand, and exported finished invoices to send back as 810 documents, which was slow and produced chargebacks when a number was mistyped. With Acumatica and IBM Sterling connected, inbound 850 documents become Acumatica sales orders automatically and posted invoices flow out as 810 documents to each partner mailbox. Orders enter the system the day they arrive, the rekeying is gone, and EDI compliance penalties drop.

What you can do

  • Render Acumatica sales invoices as X12 810 documents and place them in the IBM Sterling trading-partner mailbox.
  • Turn inbound 850 purchase order messages from IBM Sterling mailboxes into Acumatica sales orders, and 810 messages into AP bills.
  • Map each Acumatica entity to its EDI transaction so documents leave and arrive in a format the partner accepts.
  • Bridge IBM Sterling Basic or OAuth2 login on a customer host and port with Acumatica's version-locked OAuth tenant login.
  • Tag every outbound message and track inbound messages by id so no document is processed twice, with full audit and replay.

Questions

Which direction does data move between Acumatica and IBM Sterling?
Both directions, each mapped to an EDI transaction. Acumatica sales invoices and purchase orders go out through IBM Sterling as 810 and 850 documents for routing to a trading partner, and inbound EDI that Sterling received is pulled into Acumatica as sales orders, AP bills, and customers. The cadence is a polling schedule you set, since the IBM Sterling REST API pushes nothing to an external endpoint.
IBM Sterling has no invoice or purchase order endpoint, so how does the connection work?
IBM Sterling B2B Integrator is EDI middleware, not a finance system, so invoices and POs are not native REST objects. Its REST API manages trading partners, mailboxes, and mailbox messages, and business documents move through it as X12 EDI payloads. ml-connector maps each Acumatica record to its EDI transaction, POSTs the payload as a document to get a documentId, then creates a mailbox message that references it to send, and polls mailbox messages to retrieve what a partner sent.
What does IBM Sterling need on the connection side, given it is self-hosted?
Because every IBM Sterling instance runs on a customer host with no shared cloud URL, ml-connector accepts the host and Liberty HTTPS port as credentials and often needs VPN or firewall access arranged with the customer's network team. It authenticates with a dedicated non-super-user API account over HTTP Basic, since super-user accounts are rejected, or with OAuth2 client credentials on 6.2.2 and later. On the Acumatica side it stores the full instance URL and the exact endpoint version, since a mismatch returns 404.

Related integrations

Connect Acumatica and IBM Sterling

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started