Sage Intacct Integration Services
We connect billing, payment and operational systems to Sage Intacct so the ledger is populated by software rather than by export and re-key. The work covers posting rules, duplicate prevention, error handling and the audit trail, built on the REST API, with XML Web Services where an object has not moved across yet.
REST first, XML where required
The REST API has been generally available since the 2025 R1 release and is where Sage ships new objects
Replay-protected posting
A retry cannot post the same entry twice, using the platform's own control mechanism rather than hoping
A named service account
Not a shared login. It appears in your access review and its activity is traceable
Errors route, never disappear
Every rejected post lands in a queue with the Intacct response in plain language
What Sage Intacct Integration Services Usually Have to Do
Five shapes, each with a different failure mode, which is why they are scoped and priced separately rather than as one integration project.
Billing system to Intacct
Invoices, credit notes and revenue detail posted from a billing or subscription platform, with customer and item mapping, and a tie-out between what the billing system issued and what reached the ledger.
Payment processor to Intacct
Settlement detail posted as cash receipts and fee entries, structured so the later bank reconciliation can actually match. Getting this shape wrong is what makes reconciliation impossible afterwards.
Reconciliation detail →Operational system to Intacct
A field service, practice management, logistics or production system that holds the activity but not the accounting. Summary or detail-level journal entries with dimension mapping to department, location, project or class.
Master data synchronisation
Customer, vendor and item records kept consistent between Intacct and the systems around it, with a defined system of record per field rather than a two-way sync that fights itself.
Reporting and data extraction
Trial balance, transaction detail or dimension data pulled out of Intacct into a warehouse or BI layer, with the query shaped around the platform's pagination rather than against it.
Migration and parallel running
Moving onto Intacct from another ledger, where the integration writes to both systems for a period while the finance team compares them.
Posting Rules Are the Part That Takes the Time
Connecting to the API is rarely the hard part. Deciding what posts, at what grain, to which account, under which conditions. That is the work, and it is a finance conversation rather than a technical one.
Grain
Does each source transaction become its own entry, or does the day summarise? Detail gives you traceability and volume. Summary gives you a clean ledger and a harder investigation. Decided once, deliberately.
Account and dimension mapping
Including what happens when a source record carries a value with no mapping: rejected to an exception, or posted to a holding account and flagged. The default nobody chose is the one that causes the month-end surprise.
Timing and period control
What posts on the day, what posts at period end, and what the integration does when it meets a closed period. A posting that silently fails on a closed period is a reconciliation problem three weeks later.
Currency and revaluation
Which rate, from which source, applied at which point, and whether revaluation is in scope at all. Stated in the design rather than discovered at year end.
Reversal behaviour
What happens when a source transaction is cancelled or amended after it has already posted. We write a reversal or adjustment carrying the original's source reference, never an in-place edit.
Proof the run worked
A reconciliation produced by the same job that did the posting: count and value in, count and value out, difference explained. Plus a tie-out report finance can run themselves rather than asking us.
Two Failures Matter: the Duplicate Post and the Silent Drop
One overstates your numbers, the other understates them, and both are usually found weeks later by somebody reconciling.
On duplicates. Sage Intacct's XML Web Services API provides a direct mechanism: the uniqueid element in the request control block defaults to true, and the controlid on each function is checked to determine whether that operation already completed. Sage's own guidance is to use it for create and update operations, precisely because financial transactions change the state of the system. Where an integration path offers no equivalent guarantee, we carry a client-side key on every posting and check before writing. Slower, and the correct trade.
On silent drops. A batch that posts 870 of 900 records and reports success is the worst outcome available. Every run reports count and value in both directions, and a mismatch raises an alert rather than appearing in a log nobody reads. Alerting covers the run that never started, which is the failure a log-based alert cannot see.
What Happens to Each Kind of Failure
Transient faults and validation failures are different problems. Retrying a validation failure just produces the same rejection repeatedly.
What the Intacct Audit Trail Actually Gives You
Sage records who created, modified, deleted or printed a record and when. That tells an auditor the integration made an entry. It does not tell them which transaction caused it.
One named service account per integration
If three integrations share a credential, the audit trail tells you an entry was made by the integration and nothing more. Separate accounts make activity attributable and let you give each one only the permissions it needs.
The service account belongs in your access review
It is a user, and it gets reviewed like one, which means the reviewer needs a written specification of what permissions it should hold. We produce that at handover rather than leaving your team to reverse-engineer it from configuration.
Platform audit trail is not lineage
Intacct can tell you the integration created an entry. Only a source reference carried on that entry tells you which transaction in which system caused it. We write that reference on every posting. It is the difference between answering an auditor in minutes and in days.
A note on what we are not. Xylity is not a Sage Intacct certified partner and we do not resell Intacct licensing. We are an integration and automation practice that works with the platform's published interfaces. If your engagement needs licensed implementation or configuration work, we will say so and work alongside whoever holds that relationship.
The Two Sage Intacct APIs, and Which One Your Project Uses
Which one applies affects both effort and longevity. Any proposal that does not say which it is using has not looked.
REST API
Generally available since the 2025 R1 release. Sage's stated guidance is that new objects and features ship here, and it recommends REST for client applications. Authentication is OAuth 2.0 against an app registered in the Sage developer portal
XML Web Services
Still supported, labelled legacy by Sage, and feature-frozen rather than scheduled for removal. Session-based authentication with sender credentials. Still the route for objects that have not moved to REST
Throughput
Sage documents a gateway concurrency rule that can briefly hold a request, a 15-minute request timeout, guidance to keep queries under 1,000 records, and a 2,000-row cap per query call, so anything substantial is paginated by design
Commercial limits
Sage sells API capacity in performance tiers. Your allotment is a contractual question for your Sage account team, and it belongs in scoping before volume assumptions are baked into a design
Why this matters commercially. An integration written against the XML API today still works, but it will not pick up objects Sage ships only to REST. Where a client has a working XML integration and a new requirement, we usually recommend leaving the working one alone and building the new work on REST, rather than a rewrite nobody budgeted for.
Where This Fits
Sage Intacct integration is usually one component of a wider piece of work.
Finance process automation services
The full scope: accounts payable, ledger flows, reconciliation, collections, close and master data, plus how an engagement runs stage by stage.
The service page →Payment and bank reconciliation automation
What happens downstream of the cash posting, and why the shape of that posting decides whether reconciliation can work at all.
Read the detail →How we build finance automations
For your IT or security reviewer. Credential handling, audit trail, error handling, change control and the API versus RPA decision.
Read the standards →Sage Intacct Integration Services: Common Questions
What finance teams and their IT reviewers ask before scoping an Intacct integration.
Connecting the systems around Intacct to the ledger: billing and subscription platforms, payment processors, operational systems that hold activity but not accounting, and the reporting layer that reads data back out. The build covers posting rules and grain, account and dimension mapping, duplicate prevention, error handling with a working exception queue, and a source reference on every entry so the audit trail leads somewhere.
Yes. The Sage Intacct REST API reached general availability in the 2025 R1 release, and Sage has stated that new objects and features ship there and that it recommends REST for client applications. The older XML Web Services API remains supported and is labelled legacy, feature-frozen rather than scheduled for removal, so existing integrations keep working. Which one your project uses depends on the objects involved, and it is worth confirming before scope is agreed.
No. Xylity is not a Sage Intacct certified partner and we do not resell Intacct licensing. We are an integration and automation practice that builds against the platform's published interfaces. Plenty of engagements run alongside a client's existing Intacct implementation partner, who holds the configuration relationship while we build what connects to it. If your work needs licensed implementation, we will tell you rather than take it on.
Sage Intacct's XML Web Services API provides replay protection directly. The uniqueid element in the request control block defaults to true, and the controlid on each function is checked to determine whether that operation already completed. Where an integration path offers no equivalent, we carry a client-side unique key on every posting and check it before writing. Either way a failed run can be replayed safely, which makes recovery routine rather than a manual reconciliation.
It is held, not retried and not dropped. The Intacct response is translated into something a controller can act on, such as a missing dimension value, a closed period or a validation failure, and the item appears in an exception queue with an owner and an age. Transient failures such as a timeout take a different path and do get a bounded retry. The distinction matters: retrying a validation failure just produces the same rejection repeatedly.
Usually, but the approach changes. Where the system supports a file exchange or a database connection, we use that. Where it offers only a user interface, RPA becomes the route, with monitoring and an exception queue because screen automation breaks when the vendor changes a layout. We establish this in the interface assessment before quoting, because the difference between those options is the difference between a short project and a long one.
Find Out What Your Systems Actually Expose
Before any Intacct integration is scoped, we assess what each system in scope exposes: which API, which version, how it authenticates, how it throttles, and whether a sandbox exists. That assessment determines the approach and the price, and the document is yours.