Sage Intacct technical guide
Everything an engineer needs to connect Sage Intacct to Salesforce: architecture, the exact build steps with real code, field mapping, the data model, security, monitoring, and the pitfalls we design out.
Two-way Salesforce and Sage Intacct accounting sync via MuleSoft. We have shipped it across 2 client projects and 14 build tasks.
The value is one source of truth: both systems stay current, records reconcile automatically, and every error is logged for review.
We use Sage Intacct as governed middleware: Salesforce and your other systems connected once, mappings and transforms kept in one place, and scheduled flows with retries and monitoring.
Every Sage Intacct build is delivered by a senior Salesforce architect on a fixed price, tested end to end in a sandbox, deployed to your org, and backed by 30 days of hypercare. You own the result: documented, source-controlled, and free of black-box middleware lock-in.
How Sage Intacct connects to Salesforce
The real connection surface: how it authenticates, what it is built on, the endpoints and events in play, and where the reference docs live.
- Connects via
- MuleSoft (Anypoint / Composer) Sage Intacct Connector performing bi-directional sync with SalesforceSage Intacct XML Web Services via HTTP POST to the XML gatewayDataWeave transforms map Salesforce fields to Intacct dimensions and objects
- Package
- Custom build (no managed package)
- Authentication
- XML Web Services: senderId + senderPassword (partner credentials) plus company login; getAPISession returns a Session ID and a unique session endpoint used for all subsequent requests
- API type
- SOAP/XML
https://api.intacct.com/ia/xml/xmlgw.phtml (getAPISession returns a session-specific endpoint)- Reference
- Official developer docs
Key endpoints
getAPISessioncreate_sotransaction (AR invoice, ARINVOICE + lines)create_journalentry (GL journal)readByQueryreadByNameBuild this with AI agents
Copy the full playbook as a prompt for any coding agent, or install it as a Claude Code skill. Either way your agent builds with our exact approach: the architecture, the Apex code, the field mapping, the rate limits, and the pitfalls to design out. Free, no signup.
Loading the Sage Intacct playbook...What we build for a Sage Intacct integration
A MuleSoft-based bi-directional Salesforce and Sage Intacct integration: session-based XML auth cached in Mule, DataWeave transforms both ways, a nightly billing sync onto Opportunities, and reconciliation of credit change orders and GL variances.
Session-based authentication
Authenticated Sage Intacct with an XML request (sender id and password, user id, company id) returning a Session ID, cached in a Mule variable for reuse.
Salesforce to Sage push
Transformed Salesforce records into Sage XML and JSON payloads with DataWeave, batched in chunks and posted on trigger.
Sage to Salesforce nightly sync
A scheduled midnight batch that syncs billing-contact details onto Opportunities and pulls negative change orders from the AR invoice-line endpoint into a Credit Change Order Amount.
Reconciliation and ARR
Reconciled GL and journal-entry-line variances, aligned line-of-business, and mapped Intacct contract lines to update Total Current ARR and renewal-opportunity fields on Account.
Real components we ship
What you will need
What we confirm on both sides before writing a line of code.
From trigger to record, end to end
The production runtime flow, with what happens in each system.
- 01
Change in either system
Either systemA change in Salesforce or in Sage Intacct starts the sync.
$Salesforce side via flow or Change Data Capture; vendor side via webhook or scheduled pull. - 02
Transform and route
In transitThe integration layer maps and transforms the payload between the two data models.
$DataWeave or Apex converts between the Salesforce and vendor schemas. - 03
Push and scheduled pull
In transitRecords push on trigger and pull on a schedule so both sides stay current.
$An updatedSince delta filter keeps each batch small and current. - 04
Reconciled both ways
Both systemsRecords reconcile across systems, with every error logged for review.
$Conflicts resolved by rule; failures land in an Error Log object for replay.
How the data actually flows
Left to right: sources, the integration layer, Salesforce, and the outcomes it drives.
// sources feed the integration layer, Salesforce persists, outcomes ship
The objects behind the integration
The Salesforce objects we read and write, what each one is for, and the fields that carry the load.
| Object | Purpose | Key fields |
|---|---|---|
Invoice | The primary Salesforce record Sage Intacct data maps onto. | External_Id__c, Name, Status |
Account | Matched or created for the customer or company behind the record. | Name, External_Id__c |
Error_Log__c (custom) | Captures every request, response, and failure so anything can be replayed. | Payload__c, Status__c, Related_Id__c |
Sync_Log__c (custom) | Tracks the last-synced timestamp per record for delta pulls. | Last_Synced__c, Direction__c |
Salesforce objects typically in play for Sage Intacct
Build the Sage Intacct integration
Every step we follow to ship a production-grade build, with the code that matters.
Plan the integration and prerequisites
We line up both systems and the platform first.
- API access on Salesforce and your other systems, plus the Sage Intacct environment and connectors
- The objects, direction, sync pattern, and success criteria agreed up front
Connect Salesforce to Sage Intacct
We wire up the Salesforce connector securely.
- Configure the Salesforce connector with a Connected App and OAuth, or JWT for a headless flow
- Give the connector a dedicated least-privilege integration user
Connect the target systems
We bring the other endpoints into the platform.
- Configure each target connector with its own secure credentials
Design a canonical data model
We map everything to one shared shape, not point to point.
- Define a canonical model so each system maps to and from one schema, which scales as systems are added
Build the transforms
We keep all the mapping logic in one governed place.
- Build the Sage Intacct flows or recipes that move each record
- Map and transform payloads (for example, DataWeave on MuleSoft) to and from the canonical model
%dw 2.0
output application/json
---
payload map (row) -> {
External_Id__c: row.id,
AccountId: row.customerId,
Amount__c: row.total,
Status__c: upper(row.state)
}Choose the sync pattern
We pick real-time or batch per use case.
- Real-time via Platform Events or Change Data Capture, or scheduled batch with an updatedSince filter
// Real-time: Salesforce publishes a Platform Event, the iPaaS subscribes
trigger OrderEventTrigger on Order_Event__e (after insert) {
List<Sync_Task__c> tasks = new List<Sync_Task__c>();
for (Order_Event__e ev : Trigger.new) {
tasks.add(new Sync_Task__c(Order_Id__c = ev.Order_Id__c, Status__c = 'Queued'));
}
insert tasks;
}Add error handling and retries
We make it reliable at volume.
- Batch records in chunks, add retries with backoff, and route failures to a dead-letter queue
// Scheduled delta pull: only records changed since the last successful run
global class DeltaPullScheduler implements Schedulable {
global void execute(SchedulableContext ctx) {
Datetime since = IntegrationConfig.lastSync();
ExternalService.pullUpdatedSince(since); // the iPaaS flow filters by updatedSince
IntegrationConfig.setLastSync(System.now()); // watermark for the next run
}
}Pro tip: build for retries
At volume, transient failures are normal. Batch in chunks and add retries with a dead-letter queue, so a blip never means lost data.
Test in a sandbox environment
We validate before production.
- Run representative loads end to end and confirm both sides reconcile
Deploy with CI and monitor
We ship it and keep it observable.
- Promote Sage Intacct artifacts through environments with CI, and monitor the flows with alerting plus 30 days of support
Example field mapping
How Sage Intacct data lands on your Salesforce records. We tailor the full mapping to your org.
| Sage Intacct | Salesforce | Notes |
|---|---|---|
| Sage Intacct record id | Invoice.External_Id__c | Unique external id, upsert key |
| Sage Intacct number | Invoice.Name | |
| Sage Intacct customer | Account | Matched or created |
| Sage Intacct amount / total | Invoice.Total__c | |
| Sage Intacct status | Invoice.Status | Picklist value mapping |
| Created / updated at | LastModifiedDate | Enables delta sync and audit |
| Owner or rep | Invoice.OwnerId | Assignment rules or a default owner |
Rate limits and governor limits
The platform constraints we design around, so the integration stays fast and never falls over at scale.
Specific to Sage Intacct
Salesforce platform limits
Secure by design
How we keep the integration safe, least-privilege, and compliant.
Monitoring, retries, and reliability
What keeps the integration trustworthy in production, and how you know the moment something needs attention.
How we test, deploy, and hand it over
The quality gates every build clears before it touches your production org.
Common pitfalls we design out
The mistakes that quietly break integrations, and how we avoid each one.
Point-to-point sprawl
Map every system through one canonical model instead of pairwise connections.
Silent failures at volume
Add retries with backoff and a dead-letter queue with alerting.
Schema drift breaks the flow
Version the transforms and validate payloads against a contract.
No visibility when it breaks
We log every call and surface failures on a dashboard with alerts, so an issue never goes unnoticed.
Reporting drifts from reality
External-id keys and a delta timestamp keep Salesforce and the source reconciled, so reports stay trustworthy.
Gotchas specific to Sage Intacct
Sage Intacct integration: technical FAQs
How do you authenticate Sage Intacct with Salesforce?
We connect Sage Intacct using MuleSoft with secure credentials and store every secret in Salesforce Named Credentials with a permission set, so nothing is hard-coded or shipped in metadata.
Does the Sage Intacct integration handle bulk volume?
Yes. All Apex is bulkified, volume moves to Queueable or Batch Apex, and we respect the Salesforce governor limits (SOQL, DML, and callout caps per transaction).
How do you prevent duplicate records?
We upsert on a unique external-id field, so a retried or duplicate payload is idempotent and never creates a second Invoice.
How is the integration tested and deployed?
Apex tests with HttpCalloutMock cover the success, failure, and a 200-record bulk case (75 percent plus coverage). We deploy via change sets or an SFDX and CI pipeline.
What happens if Sage Intacct or Salesforce is briefly down?
Failed calls retry with backoff and land in an Error Log object with alerting, so nothing is lost and any event can be replayed.
Real-time or batch sync?
Either. We use Platform Events or Change Data Capture for real-time, or a scheduled batch with an updatedSince delta filter for high volume.
Want us to build your Sage Intacct integration?
Skip the build. In a free 30-minute call we will map your Sage Intacct flow and hand you a clear, fixed-price plan.