Sage Intacct – Adobe Commerce (Magento)

by
Integration Specification — Technical Reference
Sage Intacct ↔ Adobe Commerce (Magento)
API Key + OAuth 2.0 Token Event-Driven Middleware
62 / 100
VIABLE
Health Score
Integration Viability Score — Proprietary Assessment
Sage Intacct ↔ Adobe Commerce (Magento)
Auth Robustness16/25
Webhook / Event Support14/25
Rate Limit Generosity10/25
Documentation Quality22/25
VERDICTA viable but complex integration requiring XML-based middleware orchestration on the Intacct side paired with Adobe Commerce's REST API, best suited for mid-market B2B merchants needing real-time order-to-cash automation.
Table of Contents hide
1 Executive Summary
1.1 ⚡ Accelerate your integration roadmap
2 Logical Architecture & Data Flow
2.1 Architecture Component Breakdown
2.2 Authentication Architecture
2.3 Data Flow Diagram
3 Enterprise Use Cases
3.1 Use Case 1: Order-to-AR Invoice Automation
3.2 Use Case 2: Payment Capture to Cash Receipt
3.3 Use Case 3: Customer Account Bi-Directional Sync
3.4 Use Case 4: Product/SKU Master Data & Inventory Sync
3.5 Use Case 5: Credit Memo & Refund Reconciliation
4 Standard API Field Mapping
5 Limitations & Rate Limits
5.1 Sage Intacct Rate Limits
5.2 Adobe Commerce Rate Limits
5.3 Critical Engineering Constraints
6 Official Documentation

Executive Summary

Integrating Sage Intacct with Adobe Commerce creates a closed-loop order-to-cash pipeline where eCommerce transactions flow automatically into the general ledger, accounts receivable, and inventory modules without manual re-keying. Adobe Commerce acts as the revenue origination layer — capturing orders, customers, and payments — while Sage Intacct serves as the financial system of record for invoices, journal entries, cash receipts, and COGS. Middleware (iPaaS or custom) bridges the two platforms, translating Commerce REST payloads into Intacct XML API requests and vice versa.

⚡ Accelerate your integration roadmap

Stop wrestling with API rate limits, undocumented endpoints, and unreliable webhooks. Our engineering team designs and deploys resilient, enterprise-grade integration architectures in days. Prefer to build it in-house? Leverage our recommended middleware platform.

The primary integration surfaces are: order placement triggering AR invoice creation in Intacct; customer account sync for credit management; product/SKU sync for inventory valuation; and payment capture events writing cash receipts to Intacct. Because Intacct’s primary developer surface remains its XML Web Services API (with a newer REST API at developer.sage.com/intacct), architects must plan for XML envelope construction, session-based authentication, and Intacct’s DTD-constrained request schema alongside Commerce’s modern token-based REST API.

Logical Architecture & Data Flow

Architecture Component Breakdown

◈
Adobe Commerce REST API
Token-authenticated REST surface exposing orders, customers, products, invoices, and inventory. Supports synchronous calls and bulk async endpoints for high-volume operations.
◈
Commerce Webhook / Event Bus
Adobe Commerce emits order, shipment, and payment events via Observer/Plugin hooks or the Adobe I/O Events framework, enabling near-real-time push to middleware.
◈
Middleware / iPaaS Layer
Orchestrates translation between Commerce JSON payloads and Intacct XML envelopes, handles retry logic, error queuing, and field transformation. Examples: MuleSoft, Boomi, Celigo, custom Node.js.
◈
Intacct XML Web Services
The primary integration API for Sage Intacct, accepting HTTPS POST requests with XML envelopes. Supports session tokens obtained via login function using Web Services credentials.
◈
Intacct AR & GL Modules
Receives created invoices, cash receipts, and journal entries from the middleware. Acts as the financial ledger for all eCommerce revenue transactions.
◈
Intacct Inventory Module
Receives item master data and quantity adjustments triggered by Commerce order fulfillment events, maintaining COGS accuracy and inventory valuation in the ERP.
◈
Error & Dead-Letter Queue
Captures failed API calls, schema validation errors, and duplicate transaction guards. Essential for idempotency and reconciliation audit trails in financial workflows.

Authentication Architecture

Adobe Commerce authenticates integration requests via OAuth 1.0a (for integration tokens) or bearer tokens issued through the POST /V1/integration/admin/token endpoint using admin credentials. For server-to-server integrations, a long-lived Integration Access Token generated in the Commerce Admin is the standard pattern. Sage Intacct uses a session-based model: the middleware first posts an XML <login> function with a Web Services sender ID, sender password, company ID, user ID, and user password to obtain a sessionid, which is then included in subsequent request envelopes. Sessions expire after approximately 30 minutes of inactivity, so middleware must implement session renewal logic. Neither platform natively supports OAuth 2.0 on the inbound integration path in its classic XML API surface, making this a mixed-auth architecture requiring secure credential vaulting (e.g., HashiCorp Vault or AWS Secrets Manager).

Data Flow Diagram

graph LR
  A["Adobe Commerce\nOrder Placed"] -->|"POST event"| B["Middleware\niPaaS"]
  B -->|"XML envelope"| C["Intacct XML API\nAR Invoice"]
  C -.->|"Invoice ID"| B
  B -->|"Update order"| A
  D["Adobe Commerce\nProduct Catalog"] -->|"SKU sync"| B
  B -->|"Create item"| E["Intacct\nInventory"]

Enterprise Use Cases

Use Case 1: Order-to-AR Invoice Automation

USE CASE 4.1
TRIGGER: order_placed / order_status = processing
→ AR Invoice created in Sage Intacct
Order-to-AR Invoice Automation
When a Commerce order reaches processing status, the middleware polls GET /V1/orders?searchCriteria[filter_groups][0][filters][0][field]=status&value=processing or receives an event push. It maps order fields to an Intacct create_invoice XML function, populating CUSTOMERID, WHENCREATED, INVOICEITEMS, and CURRENCY. Idempotency is enforced by storing the Commerce entity_id as a custom field in Intacct to prevent duplicate invoices on retry.

Use Case 2: Payment Capture to Cash Receipt

USE CASE 4.2
TRIGGER: invoice paid / payment captured event
→ Cash Receipt applied to AR Invoice in Intacct
Payment Capture to Cash Receipt
Upon payment capture in Adobe Commerce (retrievable via GET /V1/invoices/{id} with state=2), the middleware constructs an Intacct create_arpayment XML request referencing the previously created invoice by RECORDKEY. This closes the AR loop and updates the GL cash account, eliminating manual bank reconciliation steps and reducing DSO.

Use Case 3: Customer Account Bi-Directional Sync

USE CASE 4.3
TRIGGER: new customer registered or Intacct customer created
→ Customer record mirrored across both platforms
Customer Account Bi-Directional Sync
New B2B customers registered via POST /V1/customers in Commerce are propagated to Intacct as AR customer records using create_customer. Conversely, customers created by finance in Intacct are synced back to Commerce. The Intacct CUSTOMERID is stored as a Commerce customer attribute to maintain a persistent cross-system key. Credit limits set in Intacct can be pushed back to Commerce’s B2B company credit module via PUT /V1/companyCredits/{id}.

Use Case 4: Product/SKU Master Data & Inventory Sync

USE CASE 4.4
TRIGGER: new product created or inventory adjustment in either system
→ Item master and stock levels synchronized
Product/SKU Master Data & Inventory Sync
Products created in Commerce via POST /V1/products trigger item creation in Intacct’s inventory module using the create_item function, mapping Commerce sku to Intacct ITEMID. Fulfillment events (shipments created via POST /V1/order/{orderId}/ship) drive inventory deduction in Intacct via create_ictransaction, keeping COGS and on-hand quantities accurate without manual journal entries.

Use Case 5: Credit Memo & Refund Reconciliation

USE CASE 4.5
TRIGGER: refund / creditmemo created in Commerce
→ AR Credit Memo posted in Intacct GL
Credit Memo & Refund Reconciliation
When a credit memo is issued in Commerce (retrievable via GET /V1/creditmemos/{id}), the middleware creates a corresponding Intacct create_aradjustment record linked to the original invoice. This ensures the AR subledger and GL remain in balance without manual override, and provides auditors with a traceable refund trail from the eCommerce transaction to the ledger entry.

Standard API Field Mapping

⚠ Note: Field names reflect canonical API schema identifiers. All endpoints verified against official documentation.
Entity Sage Intacct Field Method Adobe Commerce Field Method Type
Customer CUSTOMERID POST id GET String / Integer
Customer NAME POST firstname + lastname GET String (concat)
Customer EMAIL POST email GET String
AR Invoice WHENCREATED POST created_at GET ISO 8601 DateTime
AR Invoice TOTALAMOUNT POST grand_total GET Decimal
AR Invoice CURRENCY POST order_currency_code GET ISO 4217 String
Invoice Line ITEMID POST sku GET String
Invoice Line QUANTITY POST qty_ordered GET Decimal
Invoice Line UNIT_PRICE POST price GET Decimal
Cash Receipt PAYMENTAMOUNT POST base_amount_paid GET Decimal
Shipment DATESHIPPED PATCH created_at (shipment) GET ISO 8601 DateTime
Credit Memo ADJUSTMENTTYPE POST adjustment_negative GET String / Decimal

Limitations & Rate Limits

⚠ Risk Advisory: Validate all rate limits with vendor TAMs before production go-live.

Sage Intacct Rate Limits

Constraint Limit Detail Mitigation
Concurrent Sessions DATA_UNAVAILABLE Session concurrency limits not publicly documented; varies by subscription tier Pool and reuse session tokens; implement session renewal within middleware
API Requests/Hour DATA_UNAVAILABLE Throughput limits not published in developer documentation Implement exponential backoff; batch multiple operations in a single XML envelope using function blocks
XML Envelope Batch Size Up to 100 functions per request A single HTTPS POST can contain multiple function calls in one envelope Batch invoice line creation to reduce total request volume
Session Expiry ~30 min inactivity Sessions expire after idle period; not a hard published number Re-authenticate proactively before session expiry; cache sessionid with TTL

Adobe Commerce Rate Limits

Constraint Limit Detail Mitigation
REST API Rate Limit (Cloud) DATA_UNAVAILABLE Adobe Commerce Cloud rate limits are configurable per deployment; not universally published Configure nginx rate limiting at infrastructure level; use bulk async endpoints for high-volume writes
Bulk Async Endpoint Configurable (default no hard limit in docs) POST /async/bulk/V1/products processes operations asynchronously via message queue Use for batch product and inventory updates; poll operation status via GET /V1/bulk/{uuid}/status
Search Results Page Size Default 20, max configurable REST search endpoints return paginated results; pageSize parameter controls page size Implement cursor-based pagination using searchCriteria[currentPage] for order polling
Admin Token Lifetime 4 hours (default) Admin bearer tokens expire; configurable in Stores > Configuration > Services > OAuth Use long-lived Integration Access Tokens instead of admin tokens for server-to-server flows

Critical Engineering Constraints

▲Intacct’s XML API requires constructing well-formed XML envelopes with DTD-compliant structure for every request. Middleware must maintain an XML templating layer and cannot use standard REST/JSON libraries natively, increasing implementation complexity.
▲There is no native outbound webhook capability in Sage Intacct’s XML API. Polling-based patterns or Intacct’s Platform Services (custom triggers) are required for detecting GL/AR changes and pushing them back to Commerce, adding latency to bi-directional flows.
▲Multi-entity Intacct deployments require the middleware to pass the correct locationid or entity context in each XML envelope. Misrouted transactions post to the wrong entity and require manual reversal — a high-risk error in multi-subsidiary B2B Commerce deployments.
▲Adobe Commerce’s event/webhook system requires custom module development or the Adobe I/O Events integration for reliable push-based triggers. Out-of-the-box webhook support is not as mature as competing platforms, meaning most production integrations rely on polling Commerce REST endpoints at intervals.
▲Tax handling across both platforms requires careful mapping: Commerce calculates tax at order time, but Intacct may apply its own tax codes. A tax reconciliation strategy (pass-through vs. recalculation) must be defined before go-live to avoid AR/GL mismatches during audits.

Official Documentation


Sage Intacct
Intacct Developer Portal — XML Web Services & REST API
VIEW DOCS →


Sage Intacct
XML Web Services Guide — Authentication & Functions
VIEW DOCS →


Adobe Commerce
REST API Overview — Authentication & Endpoints
VIEW DOCS →


Adobe Commerce
Bulk & Asynchronous Web Endpoints
VIEW DOCS →


Adobe Commerce
B2B Integration Guide — Company Credit & Quotes
VIEW DOCS →


Sage Intacct
Sage Intacct REST API (New Developer Portal)
VIEW DOCS →