Exporting data from Sage Intacct before a contract ends
If a renewal, price change, residency requirement or lock-in concern is pushing you toward an exit, the documented bulk path out of Sage Intacct is the Data Delivery Service (DDS). It extracts standard and custom object data as CSV files to a cloud location, either on a daily, weekly or monthly schedule or on demand. The REST API is the route Sage Intacct recommends for client applications, and the legacy XML API remains supported, so either can carry programmatic extraction where DDS does not fit. Note that DDS requires its own subscription, so confirm its cost and whether it is active on your contract before you plan the export window.
Plan for two delivery modes. A full delivery gives you complete data sets, while a changed-records delivery sends only what has moved since the previous run, which suits ongoing parallel running after cutover. For a consistent snapshot across objects, use the Synchronization option, which extracts objects at the same point in time. It handles up to five objects at once and excludes GL Account Balance and GL Resolve, so balances need a separate route such as a report export. In multi-entity companies, frequency is set and data is extracted at the top level rather than per entity, so confirm with your administrator how each entity's data will be separated in the files.
Before you rely on DDS, check the cloud storage target. Intacct can deliver to Amazon S3, Azure Blob Storage, Box, Dropbox, Google Drive, HTTP and OneDrive, and an S3 bucket must be created in the US East (N. Virginia) region, which matters if your residency rules restrict where exported finance data lands. Ask your Sage Intacct administrator to run a test delivery, reconcile record counts against the live system, and confirm the destination meets your data handling policy. Start this check early, because the export has to be repeatable before the contract ends.
Which Sage Intacct data types export, by method and format
This table maps each Sage Intacct data type to the extraction method, file format, delivery options and documented limits that apply to it. Read it as a checklist: confirm which objects your company actually uses, then match each one to a method before you plan the export schedule.
| Data type | Export method | Format and frequency | Limits and what to confirm |
|---|---|---|---|
| Standard objects (for example, GL accounts, vendors, customers) | Data Delivery Service (DDS), full or changed-records delivery | CSV files to a cloud location, on a daily, weekly or monthly schedule or on demand | Requires a DDS subscription. Confirm the full object list available in your company's version. |
| Custom objects | Data Delivery Service, full or changed-records delivery | CSV files to a cloud location, on a daily, weekly or monthly schedule or on demand | Confirm each custom object is included in your DDS setup before you rely on it for a migration. |
| GL account balances | DDS only if excluded from Synchronization; otherwise a separate extract | CSV files, scheduled or on demand | GL Account Balance is excluded from the Synchronization option, so plan a separate extraction step for balances. |
| GL resolve data | DDS only if excluded from Synchronization; otherwise a separate extract | CSV files, scheduled or on demand | GL Resolve is excluded from Synchronization. Confirm how it is extracted in your company. |
| Synchronized extract (same point in time) | DDS Synchronization option | CSV files extracted at one point in time | Supports up to five objects at once. Group objects into batches of five or fewer and confirm the batch design with Sage Intacct. |
| Multi-entity companies | DDS run at the top level | Frequency is set once and data is extracted at the top level, not per entity | Confirm that entity-level records appear in top-level output before you map them to Odoo companies or ERPNext companies. |
| Programmatic extraction | REST API (recommended by Sage Intacct for client applications) or legacy XML API | Data returned to your application, format set by your code | Use when DDS does not cover a needed object or when you need custom logic. Confirm current API limits in the developer documentation. |
What does not export through DDS and how to work around it
Data Delivery Service covers most of what finance teams need, but its documented limits leave gaps in balances, attachments and reports. Each gap below needs its own extraction path, and each path needs confirmation from Sage Intacct before you rely on it in a migration plan.
GL account balances outside synchronization
The Synchronization option excludes GL Account Balance and GL Resolve, so a synchronized run gives you transactions and dimensions taken at one point in time but not the balances that tie them together. Plan a separate DDS delivery for these objects, scheduled to run at the same cut-off you use for the other objects. Then reconcile the balances in your target ledger against the extracted trial balance before you accept the opening position. Ask Sage Intacct whether a separate delivery can be aligned to the same timestamp.
GL resolve and point-in-time consistency
GL Resolve is also excluded from synchronized runs, which matters when you need account resolution data that matches the same extraction moment as your ledger. Treat it as a separate extraction with its own validation step. Compare row counts and control totals against a freshly pulled sample from the API, so you can see whether the two sources agree. Confirm with Sage Intacct how the object behaves when you export it on its own schedule.
Attachments and document files
The DDS documentation describes delivery of object data as CSV files, and it does not describe attachments or uploaded document files as delivery content. Attachments usually need a separate retrieval through the REST API or the XML API, which Sage Intacct continues to support for legacy use. Inventory which records carry attachments before you plan the migration, because the volume and file naming determine the effort. Confirm with Sage Intacct whether the API returns the binary files and their links to the parent records.
Reports and report output
Saved reports and their formatted output are distributed through the reporting features, which is a different path from DDS object extraction. If your auditors or board packs depend on a specific report layout, export those reports on their own and store them with the migration evidence. Record the parameters, period and entity used for each report so the figures can be reproduced in the new system. Confirm with Sage Intacct which report formats and destinations are available under your subscription.
Storage target and region constraints
Sage Intacct delivers to a set of cloud targets, and an Amazon S3 bucket must be created in the US East (N. Virginia) region. Those constraints can conflict with your data residency rules, so decide the target before you configure the schedule. If the bucket region is fixed, document the transfer path from that location into your own storage. Confirm with Sage Intacct how the delivered files are encrypted in transit and at rest, and who can access the delivery location.
Multi-entity scope of extractions
In multi-entity companies, DDS frequency is set and data is extracted at the top level rather than per entity. Entity-level files therefore need to be filtered after delivery, or pulled through the API by entity, before they map to separate Odoo companies or ERPNext companies. Confirm with Sage Intacct which fields identify each entity in the CSV output, and test the split on a copy of one month before you run the full history.
Full versus changed-records deliveries and why they matter
The choice between a full delivery and a changed-records delivery decides how much you can trust the files you hold. Sage Intacct's Data Delivery Service can export complete data sets or only the records changed since the previous delivery. Run a full delivery first, because it creates the baseline that every later incremental file depends on. Without a complete first extract, you have no reference point against which to prove that the incremental files are complete. Plan the first full run as a dated, archived snapshot that you never overwrite.
Repeated runs should then be incremental, with a periodic full delivery as a control. Reconcile each set against the source: record counts per object, control totals on amounts, and a sample of records traced back to the Intacct screen. Compare the changed-records output with the baseline plus the changes to confirm that edits and deletions were captured. Ask Sage Intacct to confirm in writing how deleted records appear in changed-records output, since that behavior determines whether your reconciliation can detect removals. Keep a log of run dates, scope and row counts for each delivery, so an auditor or migration team can follow the chain.
The Synchronization option matters for balances. It extracts several objects at the same point in time, which is essential when you need, for example, transactions that agree with their summarized balances. The option supports up to five objects at once and excludes GL Account Balance and GL Resolve, so you must derive or extract those separately and reconcile them to the ledger yourself. Confirm the object list, the time stamp behavior and the handling of transactions posted during the run with Sage Intacct before you rely on the output. Treat any mismatch between synchronized objects as an open question until you have explained it.
Cloud storage targets Intacct can deliver to
Amazon S3 is the target that most requires advance provisioning from your side. Sage Intacct documents that the S3 bucket must be created in the US East (N. Virginia) region, so the bucket location is fixed before any extract runs. Your cloud team creates the bucket, defines an IAM identity with write permission for the delivery, and decides who holds the access key pair. Retention is controlled by bucket policy, including lifecycle rules, versioning and object lock, none of which Sage Intacct sets for you.
- Region: the bucket must be in US East (N. Virginia), which affects where regulated financial data is stored.
- Access keys: the key pair belongs to your AWS account, so rotation and revocation sit with your security team.
- Retention: lifecycle rules decide how long each delivery remains before deletion or archival.
- Encryption and logging: server-side encryption and access logging are configured in your account, not inside DDS.
- Scope: restrict the IAM policy to the single bucket and prefix used for DDS.
Confirm the residency requirement with your compliance lead before creating the bucket, because the region is a fixed requirement of this target.
Azure Blob Storage is delivered to a container inside a storage account that your team owns. Your Azure administrators create the account and container, choose the region and redundancy, and generate the credential Sage Intacct uses to write. Because the credential grants write access to a store holding financial extracts, its scope and lifetime should be set deliberately. Retention depends on lifecycle management policies and on whether soft delete and immutability are enabled on the container.
- Account and container: your team creates both, so the location and naming follow your own standards.
- Credential: confirm the exact authentication method Sage Intacct supports and limit it to the one container.
- Retention: lifecycle management rules control tiering and deletion of older CSV files.
- Recovery: soft delete and versioning protect against accidental overwrites of a delivery.
- Monitoring: enable diagnostic logs on the storage account to record each write.
Confirm the supported credential type and the region options with your Azure administrators and the current Sage Intacct documentation before provisioning.
Box and Dropbox are business file-sharing services that Sage Intacct can deliver to. Both are hosted by their vendors, so the files sit in a tenant your organization pays for but does not run. Your administrators create a dedicated folder, connect the delivery through an account or app authorization, and decide which user or service identity owns that connection. Retention follows the retention and legal hold features of the tenant plan you hold, which you should confirm in the vendor's admin console.
- Dedicated folder: keep DDS output in its own folder so access can be granted narrowly.
- Authorization: the connection is tied to a user or app identity, so plan for offboarding and token revocation.
- Retention: check whether your plan supports retention policies or legal holds on the folder.
- Data location: confirm where the vendor stores your tenant data, since residency is set by the vendor and plan.
- Sharing: disable external link sharing on the DDS folder to avoid exposing financial extracts.
Confirm the authorization method and data location commitments with each vendor, since neither is defined by the Sage Intacct documentation summarized here.
Google Drive and OneDrive are consumer-grade and productivity-suite file services that Sage Intacct can deliver to. Your team must decide whether the target is a personal account or a managed organizational account, because a personal account is outside your administrative controls. The connection is authorized by an account holder, so the identity and its lifecycle should be defined in advance. Retention and access depend on the admin settings of your Google Workspace or Microsoft 365 tenant.
- Account type: use an organizational account under IT management, not an individual's personal drive.
- Authorization: the account holder's authorization is the access path, so plan for departures and password resets.
- Retention: apply Vault or retention labels, or the equivalent Microsoft 365 policies, to the delivery folder.
- Sharing controls: restrict external sharing and domain-level link settings for the folder.
- Data residency: confirm where your Workspace or Microsoft 365 tenant stores data for your region.
Confirm with your Google or Microsoft administrators which retention features your edition provides before approving either target.
The HTTP target delivers files to an endpoint you specify, which makes it the most flexible option and the one that most depends on your own receiving service. Your platform team must run a server that accepts the delivery, authenticates it, stores the files and handles failed transfers. Because you control the endpoint, you also control retention, encryption at rest and the audit trail. Confirm the authentication options and transport requirements in the Sage Intacct documentation before building the receiver.
- Receiver: build and operate the endpoint, including availability and capacity for large extracts.
- Authentication: confirm which methods the delivery supports and enforce them at the receiver.
- Transport: require encrypted transport and validate the certificate chain.
- Retention: implement storage, rotation and deletion rules that match your records policy.
- Verification: compare file counts and checksums on receipt to detect partial transfers.
The HTTP target gives the most control, but it also makes your team responsible for every control on the receiving side.
Run a complete export in the right order
This sequence moves Sage Intacct data out in a verified order, so that every extract can be tied back to the ledger before anyone relies on it. The result is a baseline copy, a synchronized snapshot, and a schedule of changed-record deliveries that carries the copy forward until cutover.
Confirm the DDS subscription and admin roles
Confirm with your Sage Intacct account team that Data Delivery Service is licensed on your company, because DDS requires a separate subscription. Identify which users hold the administrator roles needed to configure deliveries, and record who will own the export job after go-live. The step is complete when you have written confirmation of the subscription and a named owner for each role.
Inventory objects and entities
List every standard and custom object you need, including general ledger detail, customers, vendors, and any custom objects that hold finance or audit data. For multi-entity companies, note that DDS frequency is set and data is extracted at the top level rather than per entity, so confirm that the top-level extract includes every entity you must migrate. Compare the inventory with your reporting and audit requirements. The step closes when the object list is signed off by finance and the audit contact.
Choose and test the storage target
Select one of the cloud storage targets that DDS supports, such as Amazon S3, Azure Blob Storage, Box, Dropbox, Google Drive, HTTP or OneDrive. If you choose Amazon S3, the bucket must be created in the US East (N. Virginia) region, so check this with your cloud team before configuration. Confirm that the target is under your organization's control, that access is limited to named service accounts, and that encryption and retention settings meet your policy. The step is complete when a test file can be written to and read from the target.
Run a full baseline delivery
Configure a DDS delivery that exports complete data sets for the objects in your inventory, and run it on demand so you control the timing. Keep the job log and the list of files produced, since this baseline is the reference for every later comparison. The step closes when all files for the baseline have arrived in the target and the job log shows no failed objects.
Run a synchronized extract
Run a delivery with the Synchronization option so that the objects are extracted at the same point in time. Note the limits: synchronization supports up to five objects at once and excludes GL Account Balance and GL Resolve, so extract those separately and document how their point in time differs from the synchronized set. Ask Sage Intacct to confirm the current limits for your company and object set before you design the job. The step closes when you have one consistent snapshot with a documented extraction time.
Reconcile row counts and control totals
For each file, compare row counts with the record counts shown in Sage Intacct, and compare control totals such as debit and credit sums, balances by period, and entity totals against the ledger reports taken at the same point in time. Investigate every difference before moving on, and record the reconciliation in a sign-off sheet that finance and audit both review. The step is complete when every object reconciles or each variance has a documented and approved explanation.
Store and hash the files
Move the verified files into your controlled archive, record a cryptographic hash for each file, and store the hash list apart from the files. Keep the job log, the reconciliation sheet and the hash list together so that anyone can later confirm that a file has not changed. The step closes when a second person has recomputed a sample of hashes and matched them to the list.
Schedule changed-record deliveries until cutover
Configure recurring DDS deliveries that export only records changed since the previous delivery, using the frequency your cutover plan needs, with the top-level setting for multi-entity companies. Repeat the reconciliation on each cycle, comparing changed-record counts with the change activity in the ledger. Keep a final full delivery planned before cutover so the target system starts from a complete and reconciled data set. The step is complete when the last delivery before cutover has been reconciled and archived.
Questions buyers ask before exporting Sage Intacct data
Is Data Delivery Service included in a Sage Intacct subscription?
No. Data Delivery Service requires a separate DDS subscription, so it is a cost line to confirm before you plan an export. Sage Intacct's help documentation describes DDS as a subscription service that extracts company data to a cloud location as CSV files, on a schedule or on demand. Ask your Sage Intacct account contact to confirm the current DDS price, what it covers in your contract, and whether the subscription must be active during the export window. Also confirm whether any cloud storage provider you plan to use carries its own charges.
How much effort does a full Sage Intacct export take?
The effort depends on the number of objects, the number of entities, and the total data volume, and no single duration applies to every company. Sage Intacct does not publish a general export time in the material we reviewed, so ask Sage Intacct for an estimate based on your object list and data history. In multi-entity companies, DDS frequency is set and data is extracted at the top level rather than per entity, which reduces the number of separate jobs but still means you must check that every entity's data appears in the output. Run a trial delivery on a subset of objects first to measure file sizes and timing in your own environment.
Can our team run a Sage Intacct data export without outside help?
Often yes, if you have someone who can administer Sage Intacct, configure a cloud storage target, and validate the resulting CSV files. The DDS setup itself is a configuration task in the Sage Intacct interface, but the harder work is deciding which objects to extract, confirming that the files are complete, and mapping them into the target system. Finance staff know what the data means, while IT owns the storage target, access controls and retention. If neither group has done a bulk extraction before, a fixed-scope engagement can cover the setup and validation while your team keeps ownership of the outcome.
What do finance and IT each need to provide for the export?
Finance needs to confirm which entities, periods, objects and reports are in scope, and to sign off on reconciliation totals before any file is treated as complete. IT needs to provide a cloud storage target, decide who can read the delivered files, set retention and encryption rules, and keep the credentials used by the delivery job under control. Both teams should agree on how often deliveries run, whether they capture full data sets or only changed records, and who receives failure alerts. Write these decisions down before the first run, because they determine what the archive can be used for later.
How do custom objects fit into a Sage Intacct export?
DDS extracts standard and custom object data as CSV files, so custom objects can be included when they are available to the delivery service. Confirm the exact list of custom objects in your company configuration before you build the export scope, because a missing object is easy to overlook. Custom fields and relationships may not map one to one into an open-source data model, so document each object's fields, keys and parent-child links alongside the files. Plan a validation step that compares record counts and key totals for custom objects against Sage Intacct reports.
How do the synchronization limits affect what we export together?
The Synchronization option extracts objects at the same point in time, which matters when you need consistent balances across related objects. It supports up to five objects at once and excludes GL Account Balance and GL Resolve, so those objects need a separate handling plan. Group related objects into batches of five or fewer when you need a consistent snapshot, and confirm with Sage Intacct how it handles objects you extract outside a synchronized batch. Test a full run before relying on the output for reconciliation or migration.
How long should the export window be, and how do full and changed-records deliveries differ?
Set the window from your measured run time on a test extract, not from an assumed figure. A full delivery exports complete data sets and suits a one-time migration or a periodic archive, while a changed-records delivery exports only records changed since the previous delivery and suits ongoing synchronization. Plan a full extract as the baseline, then schedule changed-records deliveries between full runs to reduce load. Schedule exports outside month-end close, and confirm with Sage Intacct how daily, weekly or monthly frequencies apply to your entities.
What to plan before renewal or termination
Leaving Sage Intacct is mostly a planning exercise run against your contract calendar. The items below cover what to confirm, export and retain before notice deadlines pass, and how the data will be loaded into the target system afterward.
Confirm DDS and API access
Data Delivery Service requires its own subscription, so check whether your current contract includes it and whether the REST API or legacy XML API is enabled for your company. Ask Sage Intacct in writing which objects and history are included in your subscription and whether any export capacity is limited during the notice period. Without this, you may find the extraction tool is unavailable when you need it most.
Schedule a full export early
Run a complete DDS delivery, not only a changed-records delivery, well before any notice deadline so you hold a baseline copy of every standard and custom object. Repeat it at intervals so the final cutover delta is small. In multi-entity companies, remember that frequency is set and data is extracted at the top level, so confirm every entity's records appear in the output.
Plan a read-only retention period
Ask whether your contract provides a read-only window after termination and how long it lasts. Use that window to reconcile trial balances, open payables and receivables, and period-end reports against the exported files. Record the dates in writing, because a closed account can end access to reports you may still need for audits or tax queries.
Archive audit trails and approvals
Export or capture audit trail data, approval history and user change records separately from the main ledger extract, and confirm they are included in DDS output. Auditors often ask for who approved what and when, which a balance file alone does not show. Store these archives in a location your compliance team controls, with a documented retention schedule and integrity checks.
Agree the target import path
Decide how exported CSV files will enter the new system before you rely on them. Odoo can import CSV and Excel files into business objects and recommends External IDs when importing from a third-party application, so keep the source record keys stable. ERPNext Data Import uses downloadable templates and works best in batches of a few thousand records, so budget time for test loads and reconciliation.
Confirm post-termination data access
Ask Sage Intacct in writing what happens to your data after the contract ends, including deletion dates, the format of any final export, and who can request it. Confirm that the cloud storage target you use for DDS deliveries, such as Amazon S3, Azure Blob Storage or Google Drive, is under your own account so files remain available after the subscription closes.
Verifying an export before you rely on it
Treat a Data Delivery Service delivery as unverified until you have reconciled it against Sage Intacct itself. A file landing in your cloud storage location proves that a job ran, not that it captured what you need. Start with record counts for each object you extracted, comparing the row count in every CSV with the record count you pull from Sage Intacct for the same object and the same point in time. Where you used the Synchronization option, confirm that the objects in that run were all taken at the same moment, since that is the purpose of the option. Note that GL Account Balance and GL Resolve are excluded from Synchronization, so balances need their own handling, described below.
Next, test the financial content. For control totals, compare debit and credit sums, account balances at period end and the totals for each entity against Sage Intacct reports run for the same dates. In a multi-entity company, extraction happens at the top level, so the entity split has to be checked deliberately: trace a sample of transactions from each entity through the export and confirm that the entity, dimension and document reference fields match the source. Make the sample deliberately wide, covering intercompany entries, reversals and transactions dated near the cut-off. Record which fields you checked, the sample you chose and why, and any differences found and how each was resolved. If a difference traces to the delivery mode, such as a changed-records file that omitted a later edit to an earlier record, capture that in the log before you rerun anything.
Finally, check file integrity and keep the evidence. Confirm that each file opens, that encoding and delimiters parse consistently, that checksums recorded at delivery match the copies you store, and that the file names identify the object, the run date and the delivery type. Store the reconciliation workbook, the report exports used as the comparison baseline and a named sign-off from finance and the system owner in the same controlled location. This record is not an audit report or a certification, and an independent auditor will still judge your controls. It does, however, show that you could reproduce the extract, explain its scope and detect its gaps, which is the evidence most assessments ask for first.
How DeployOpen scopes and delivers an exit export
DeployOpen treats an exit export from Sage Intacct as a fixed-scope engagement that starts with your data, not a tool. We agree in writing which Data Delivery Service objects, delivery mode and storage target are in scope, then build, test and document the extraction so your team can repeat it.
How we scope
- Inventory which standard and custom objects your target platform needs, including GL history and dimensions.
- Confirm whether you need full deliveries, changed-records deliveries, or both, and the cutover date.
- Confirm your DDS subscription, the storage target, and whether your company runs multiple entities.
- Agree deliverables, timelines and acceptance tests in writing before any extraction work begins.
How we build
- Configure DDS schedules and synchronized extractions, respecting the five-object limit and the GL exclusions.
- Run multi-entity extractions at the top level, then split files by entity in a controlled, documented step.
- Reconcile record counts and control totals against Sage Intacct reports for every exported object.
- Test the export in a non-production copy of the target platform before any production import.
How we hand over
- Document each object, file layout, schedule and storage path, so the export can be rerun without us.
- Deliver reconciliation reports showing source totals, file totals and exceptions for your sign-off.
- Provide runbooks for the GL Account Balance and GL Resolve data that must be extracted another way.
- Store credentials and access keys in your own secrets tooling, with access limited to named staff.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover reruns of the export during a parallel-run period before Sage Intacct access ends.
- Confirm with Sage Intacct and your auditors how long you must retain exported records.
- Ask for retainer terms, response expectations and out-of-scope items in the quote.
