How to Export Data from Sage Intacct: API Limits, DDS, and Portability

How to Export Data from Sage Intacct: API Limits, DDS, and Portability

Sage Intacct gives you four primary ways to get data out: UI report exports (CSV, Excel, PDF), the Data Delivery Service (DDS) for bulk extraction to cloud storage, the XML Web Services API for programmatic reads, and the newer REST API for lighter integrations. Each method has different throughput limits, cost implications, and data-coverage trade-offs. This guide breaks down each option with specific technical details so you can pick the right extraction approach for a one-time migration, recurring sync, or full data-portability exercise.

What are the main ways to export data from Sage Intacct?

Sage Intacct provides multiple extraction paths, each suited to different volumes and use cases. Here's a practical breakdown.

UI report exports

There are three core ways to export data via the User Interface: List Views (the most basic export path), standard application reports, and Custom Report Writer (CRW) reports.

Export format options:

• Standard reports: HTML, CSV, PDF, or Excel
• Custom reports: Word, Excel, CSV, or Text

A few things to know:

• Custom reports must be memorized before the Export button appears. If you skip this step, you won't see the export option.
• Reports can be delivered on a schedule to OneDrive/Office365, Dropbox, Box, Google Drive, or Amazon S3 — useful for automated delivery to a data warehouse staging area.
• CRW is part of the core Sage Intacct subscription; no extra license is required for report-based exports.
• Custom reports can also be read programmatically using the readReport API function, enabling automated extraction without manual UI clicks.

When to use it: Ad hoc pulls, auditor requests, quick reconciliations, or scheduled deliveries of formatted financial statements. Not suitable for extracting hundreds of thousands of transactional records at scale — there is no bulk pagination, and exports are bounded by report row limits.

Data Delivery Service (DDS)

Sage Intacct Data Delivery Service (DDS) is a bulk extraction feature that exports entire object tables as CSV files to a configured cloud storage destination. DDS is the primary tool for data warehouse loads and large-scale migrations.

Key characteristics:

• DDS jobs can be scheduled or triggered on demand from the Sage Intacct UI, or triggered on demand via API.
• Output is always CSV only — no JSON, Parquet, or other formats.
• Supported destinations: Amazon S3, Box, Dropbox, Google Drive, and any HTTP-accessible endpoint. Azure Blob Storage is supported by providing a SAS URL as the HTTP destination.
• DDS is a paid add-on. Verify the subscription is active under Company > Admin > Subscriptions before building any pipeline around it.
• DDS supports certain Sage Intacct standard objects and all custom platform objects. Not every standard object is DDS-eligible — see the partial coverage table below.
• DDS always extracts from the top-level company, not per entity. For multi-entity companies, all entity records are combined in the output; you must filter by entity identifiers post-extraction.

DDS object coverage — commonly needed objects:

This table covers the most commonly requested objects. Always verify against Sage's published DDS Objects reference before finalizing a pipeline design, as coverage expands with product updates.

When to use it: Data warehouse loads, analytics pipelines, cross-system reporting, or full extractions for a migration staging area. DDS is the right tool when you need complete object-level dumps rather than filtered queries, and when you want to avoid consuming API transactions from your Performance Tier allocation.

XML Web Services API

The XML Web Services API is the most flexible extraction surface. For data reads, the key functions are query, readByQuery, read, and readReport.

• query: The newer function. Accepts filter expressions composed of XML elements with a well-defined schema. Recommended for new integrations.
• readByQuery: The legacy function. Accepts a simple string for the query definition. Still widely used and fully supported.
• Both functions cap results at 2,000 records per call. Larger datasets require multiple paginated calls using readMore, each counting as a separate transaction.
• Pagination uses a result ID from the original call. Using the result ID ensures paged results come from the same originating query — important if data is changing between pages.

Authentication: Session-based using XML login credentials (sender ID + sender password + user credentials). Each session token has a finite lifespan.

When to use it: Targeted extractions with filters, delta syncs based on WHENMODIFIED timestamps, extracting objects not supported by DDS, or downloading attachments. The XML API provides the most granular control over what you extract.

REST API

The Sage Intacct REST API uses standard HTTP verbs and predictable URLs to operate on objects and data. It uses OAuth 2.0 Bearer token authentication, which is simpler to implement than XML session credentials for most modern development environments.

Current limitations versus the XML API:

• The REST API covers a subset of the objects available via XML. Complex transaction objects (multi-currency AP/AR, consolidated entities) may not yet be available via REST endpoints.
• REST API usage is tracked separately: the Usage Insights report (Company → Admin → Usage Insights) currently shows only XML API transactions. REST API usage appears in the developer workspace, not the same dashboard.
• Rate limit specifics for the REST API are not publicly documented at the same level of detail as the XML Performance Tier model. Sage's guidance is to treat REST API calls as metered and apply the same exponential backoff patterns as the XML API.

Object coverage comparison:

When to use it: New integrations where you prefer RESTful patterns and OAuth. For bulk extraction or migration work, the XML API currently provides broader coverage and better-documented limits.

What are the Sage Intacct API rate limits and transaction costs?

Sage Intacct enforces API transaction limits under a Performance Tier model. The default tier (Tier 1) allows 100,000 transactions per month and is automatically applied to every customer at no extra cost.

What counts as a transaction

• Each query, readByQuery, create, update, or delete call = 1 transaction
• A readMore pagination call = 1 transaction
• A query returning 5,500 records = 3 transactions (2,000 cap forces 3 pages: calls 1, 2, 3)
• A create of five AP Bills with ten line items each = 5 transactions (line items don't add to the count — only header-level operations are metered)
• Each Smart Event firing on a metered object = 1 transaction
• Each AJAX page script execution = 1 transaction

Transaction budget math for a full extraction

To estimate API cost for extracting an object without DDS:

transactions_needed = ceil(record_count / 2000)

Examples:

• 10,000 customers → 5 transactions
• 200,000 GL entries → 100 transactions
• 50,000 AP bills → 25 transactions

An extraction covering 500,000 total records across non-DDS objects would consume approximately 250 transactions — well within Tier 1. The real risk is not the extraction itself but ongoing transaction consumption from integrations, Smart Events, and AJAX scripts running concurrently.

Overage pricing and tier comparison

Overage rate: $0.15 per pack of 10 transactions above the monthly limit.

Overage calculation example: 120,000 transactions in a month → (20,000 ÷ 10) × $0.15 = $300 overage charge.

Performance Tier comparison:

*Tier 2+ pricing is negotiated with Sage Intacct directly. When monthly overages consistently exceed ~$400–500, upgrading tiers typically becomes cost-effective versus paying per-pack overages.

Concurrency limits

Sage Intacct expresses concurrency limits as application / company. For example, "6 / 8" means any single application may hold up to 6 concurrent API processes, while the company total across all applications is capped at 8.

At Performance Tier 1, each company is limited to one concurrent offline (asynchronous) process. This matters for bulk jobs — only one asynchronous extraction can execute at a time per company.

A tenant on the default service level may also be limited to as few as two concurrent synchronous connections to the gateway. Spawning more parallel threads than this will immediately generate 429 errors.

Request size and timeout constraints

• Asynchronous requests: capped at 500,000 characters per request
• Synchronous requests: time out after 15 minutes
• Recommended record batch size for write operations: fewer than 100 records per request. If elapsed time exceeds 5 minutes, Sage recommends reducing the request size.

How to handle 429 rate-limit errors

A 429 error means your API client has hit its assigned concurrency or rate limit. Common causes: frequent polling loops or concurrent request spawning that exceeds the application-level limit.

Recommended handling:

import time
import random
 
def call_with_backoff(api_fn, max_retries=5):
    for attempt in range(max_retries):
        try:
            return api_fn()
        except RateLimitError:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
    raise Exception("Max retries exceeded")

Exponential backoff with jitter (a random offset added to each retry interval) prevents thundering-herd scenarios — the situation where multiple integrations hitting the same retry interval simultaneously amplify the load spike rather than relieving it.

XML response for a timeout error looks like:

<errormessage>
  <error>
    <errorno>GW-0011</errorno>
    <description>Request timeout. Reduce your request size.</description>
    <correction>Split the request into smaller batches.</correction>
  </error>
</errormessage>

DDS delivery failure surfaces as a job status of Failed in the DDS job history UI, with an error message indicating the specific cause (typically authentication failure to the destination cloud storage).

The hidden transaction drain: Smart Events and forgotten automations

This deserves its own section because it's the most common cause of unexpected overage charges — more common than extraction scripts.

What consumes transactions beyond your API calls:

• Smart Events configured on high-volume objects (AP Bill, AR Invoice, Sales Order lines)
• AJAX page scripts that execute on record open or save
• Platform API calls from custom applications
• Any traffic from your Web Services Sender ID

Smart Events that were prototyped years ago and never decommissioned are a recurring source of overage charges. A Smart Event firing on every AP bill save in a company processing 10,000 bills per month consumes 10,000 transactions — 10% of the Tier 1 limit — from a single automation that may no longer be needed.

Diagnostic steps:

1. Navigate to Company → Admin → Usage Insights → API Usage
2. Filter by Sender ID to isolate which application or automation is generating volume
3. Cross-reference high-volume Sender IDs against your active Smart Events (Company → Platform Services → Smart Events)
4. For each active Smart Event, verify it has a current business owner and a documented purpose
5. Decommission any Smart Event with no current owner or whose trigger condition fires on high-frequency objects without a clear return on investment

Approximate transaction cost of common automations:

Before blaming your export scripts for high transaction counts, complete this audit. The extraction is rarely the problem.

How does Sage Intacct DDS scheduling work?

DDS has specific throttle rules that differ from the general API limits:

• Full extract: Run once every 24 hours maximum per object. Running a second full extract within 24 hours will queue — or cancel — the second job.
• Change extract (delta): Run once per hour maximum per object.
• Queue constraint: Only one job of the same object type is allowed in the queue or processing state at a time. If you submit a second job for the same object while the first is queued, the second job is canceled (not queued behind it).
• Synchronized runs: You can request changed records for up to five objects in a single synchronized run.
• Time zone: DDS jobs execute based on the time zone configured in your company information, not UTC. If your company is set to US Pacific (UTC-8) but your data team expects UTC-aligned delivery windows, schedules will be misaligned by 7–8 hours. Verify under Company settings before configuring your first delivery.

The most common DDS failure: cloud storage authentication

The most frequent cause of DDS delivery failure is Sage Intacct losing access to the destination cloud storage account. Cloud storage providers often require re-authentication after a set period — for example, every 10 days for some OAuth-connected providers like Dropbox and Box.

What the failure looks like: In the DDS job history (Company → Data Delivery Service → Delivery History), the job status shows Failed with an error such as: Unable to connect to destination. Verify credentials and retry.

Prevention:

1. Configure a monitoring alert on DDS job status — don't assume scheduled jobs succeed
2. For S3 destinations, use IAM role-based access (not access key credentials) to avoid key rotation failures
3. For Box/Dropbox destinations, set a calendar reminder to re-authenticate before the provider's session expiration
4. Test the destination connection from the DDS configuration UI after any credential rotation

How to extract data from Sage Intacct using the XML API

The most common extraction pattern is a filtered readByQuery or query call, paginated with readMore. Here's a working example pulling AP Bills modified after a given timestamp:

<?xml version="1.0" encoding="UTF-8"?>
<request>
  <control>
    <senderid>YourSenderID</senderid>
    <password>YourSenderPassword</password>
    <controlid>export-apbills</controlid>
    <uniqueid>false</uniqueid>
    <dtdversion>3.0</dtdversion>
  </control>
  <operation>
    <authentication>
      <login>
        <userid>api_user</userid>
        <companyid>YourCompanyID</companyid>
        <password>YourUserPassword</password>
      </login>
    </authentication>
    <content>
      <function controlid="readAPBills">
        <readByQuery>
          <object>APBILL</object>
          <fields>*</fields>
          <query>WHENMODIFIED &gt; '06/01/2026'</query>
          <pagesize>2000</pagesize>
        </readByQuery>
      </function>
    </content>
  </operation>
</request>

Set pagesize to 2000 (the maximum) to minimize transaction count. When the response includes numremaining > 0, call readMore with the returned result ID to get the next page. Each readMore is one additional transaction.

Paginated extraction loop (Python pseudocode):

def extract_object(object_name, query_filter="", fields="*"):
    records = []
    
    # Initial query
    response = readByQuery(object_name, query_filter, fields, pagesize=2000)
    records.extend(response["data"])
    result_id = response["result_id"]
    num_remaining = response["numremaining"]
    transactions_used = 1
    
    # Paginate
    while num_remaining > 0:
        response = readMore(result_id)
        records.extend(response["data"])
        num_remaining = response["numremaining"]
        transactions_used += 1
    
    print(f"Extracted {len(records)} records in {transactions_used} transactions")
    return records

To extract a full object table for migration:

1. Start with readByQuery using an empty <query/> element and pagesize of 2000
2. Loop readMore until numremaining="0"
3. Write results to storage as you go — don't accumulate everything in memory
4. Track transaction count: 50,000 records = 25 transactions; 200,000 records = 100 transactions

Delta sync tip: Filter by WHENMODIFIED > {last_sync_timestamp}. A delta sync of 200 changed customers = 1 transaction; a full re-read of 8,000 customers = 4 transactions. Delta sync is the single most effective mechanism for controlling API costs in ongoing integrations.

How to extract Sage Intacct attachments (SUPDOC)

Attachments are the most underestimated part of any Sage Intacct extraction. DDS does not export binary attachments. Every file must be downloaded individually via API.

The attachment data model:

Sage Intacct stores attachments in the SUPDOC (Supporting Document) object. Each SUPDOC record contains metadata and references to one or more SUPDOCFOLDER entries. The actual binary file is retrieved via a separate API call that returns a base64-encoded payload.

Extraction sequence:

<!-- Step 1: Query SUPDOC records linked to a transaction -->
<readByQuery>
  <object>SUPDOC</object>
  <fields>SUPDOCID, SUPDOCDESC, SUPDOCFOLDERNAME, CREATEDBY, WHENMODIFIED</fields>
  <query>WHENCREATED &gt; '01/01/2020'</query>
  <pagesize>2000</pagesize>
</readByQuery>
 
<!-- Step 2: Read the actual attachment content -->
<read>
  <object>SUPDOC</object>
  <keys>SUPDOCID-001</keys>
  <fields>SUPDOCID, ATTACHMENTS</fields>
</read>

The ATTACHMENTS field returns base64-encoded file content. Decode and write to disk per file.

Volume expectations: A company with 5 years of AP invoices and 3 attachments per bill at 10,000 bills/year has approximately 150,000 attachment files. At 2,000 SUPDOC records per API call, the metadata extraction alone requires 75 transactions. Each attachment download is an additional read call — so 150,000 attachments = 150,000 transactions, consuming 1.5× the monthly Tier 1 limit in a single run.

Practical approach for large attachment sets:

• Request a temporary Tier 2 upgrade from Sage for the duration of the migration
• Run attachment extraction in off-peak hours to avoid concurrency conflicts
• Process attachments in batches of 5,000–10,000 with checkpoint logging so you can resume on failure
• Validate file integrity by comparing byte counts against the source record

Which Sage Intacct objects can you export?

XML API / REST API: Virtually any standard or custom object — GL accounts, journals, AP bills, AR invoices, customers, vendors, employees, projects, contracts, inventory items, purchase orders, sales orders, and all custom platform objects. The XML API is the broadest extraction surface.

DDS: Supported standard objects (see table above) plus all custom platform objects. Check DDS eligibility for each object before building a pipeline.

UI Reports: CRW reports can report on fields from almost any record or transaction, including related data. Sage Intacct includes over 150 built-in reports covering GL, AR, AP, cash management, and more.

What are the data portability limitations of Sage Intacct?

Sage Intacct is a cloud-hosted SaaS product. You don't have direct database access. Every byte of data you extract goes through one of the channels described above. Here are the practical constraints:

No "Export Everything" button. There is no single action that dumps your entire Sage Intacct tenant into a portable format. You must extract each object type individually and assemble the complete picture yourself.

Multi-entity complexity. DDS always extracts from the top-level company. To separate entity-level data post-extraction, filter on the LOCATIONID field (which maps to the entity identifier in multi-entity configurations) in the exported CSV files.

Custom fields require verification. Custom fields may not be automatically included in DDS sync configurations. For each standard object with custom fields appended via Platform Services, navigate to the object's DDS configuration and verify the Sync option is enabled for each custom field. Custom objects created entirely via Platform Services include all custom fields by default.

Encoding. Sage Intacct stores all data in UTF-8. If your target system expects a different encoding (common in legacy on-prem ERPs), handle conversion explicitly in your pipeline — don't rely on implicit conversion.

Attachments are not included in DDS. Plan separate API-based attachment extraction for any migration that requires document portability. See the attachment section above for volume estimates.

Dimensional relationships must be reconstructed. Sage Intacct's dimensional model includes departments, locations, classes, projects, items, employees, vendors, and customers as separate dimension tables. Many transaction objects contain denormalized fields from related tables to reduce joins — for example, the CUSTOMER record includes many contact fields that are stored in a related CONTACT table. When loading into a target system with a normalized schema, you'll need to map these flattened fields back to their proper relational positions.

How to plan a full data extraction from Sage Intacct

1. Inventory your objects. List every object type required: GL accounts, chart of accounts, dimensions, customers, vendors, employees, AP transactions, AR transactions, journal entries, projects, contracts, purchase orders, sales orders, inventory items, time entries, and custom objects.

2. Check DDS eligibility. Use the table above as a starting point. For each object, determine if it's DDS-supported. DDS for eligible objects; API for everything else.

3. Calculate your transaction budget. For non-DDS objects: ceil(record_count / 2000) transactions per object. Add: attachment downloads (1 transaction per attachment file), Smart Event overhead during migration window, retry overhead (typically 5–10% of base calls). Compare total against your Performance Tier limit. If you'll exceed Tier 1 (100,000 transactions), contact Sage to arrange a temporary tier upgrade before starting.

4. Configure and test cloud storage. Define a cloud storage destination in the DDS UI before running any jobs. Test the connection explicitly — don't discover authentication failures during your migration window. For S3, use IAM roles rather than static credentials.

5. Run DDS for bulk objects. Execute full-extract DDS jobs for all eligible objects. These run asynchronously and do not consume API transactions from your Performance Tier allocation.

6. Use API for remaining objects and attachments. Script readByQuery loops for non-DDS objects. Extract attachments via SUPDOC reads. See the transaction budget math above for attachment volume estimation.

7. Separate multi-entity data. Filter all extracted CSV files by LOCATIONID to create per-entity datasets if your migration target requires entity-level separation.

8. Validate record counts. Compare extracted record counts against Sage Intacct list views and summary reports. Common discrepancy causes: entity-level filtering issues, date-range mismatches, soft-deleted records included or excluded unexpectedly.

9. Map dimensional relationships. Extract all dimension tables (DEPARTMENT, LOCATION, CLASS, PROJECT, CUSTOMER, VENDOR, EMPLOYEE). Reconstruct foreign key relationships for your target system's schema. Document which denormalized fields in transaction objects map back to which dimension table columns.

Common mistakes when exporting from Sage Intacct

Ignoring the DDS subscription requirement. DDS is a paid add-on. Without it, your only bulk option is the API, which will consume significant transactions on large datasets.

Running full extracts too frequently. The DDS throttle is one full extract per object per 24 hours. Schedule accordingly, or use change extracts for incremental updates.

Not accounting for concurrent session limits. At Tier 1, the company is limited to two concurrent synchronous connections. Spawning too many parallel threads immediately produces 429 errors.

Forgetting Smart Event overhead. AJAX scripts, Smart Events, Platform API calls, and Web Services Sender ID traffic all count toward your transaction meter. Audit these before running a large extraction.

Skipping attachment planning. Companies often realize mid-migration that they need attachments and haven't budgeted the transactions or time for attachment extraction.

Skipping data validation. Exported data can have null values in unexpected places, especially for optional fields on older records. Check for null columns in DDS output before loading into a target system.

Not re-authenticating DDS cloud storage. OAuth-connected destinations (Box, Dropbox) may require re-authentication every 10 days. Build monitoring around delivery confirmation status.

When to use DDS vs. API vs. reports for Sage Intacct exports

What you should know before migrating data out of Sage Intacct

Data portability from Sage Intacct is achievable but requires planning across four dimensions: object coverage (what's DDS-eligible vs. API-only), transaction budget (how many API calls will the extraction consume), attachment volume (how many files need individual downloads), and dimensional mapping (how to reconstruct relational structure in the target system).

The biggest operational risks are:

1. Transaction overages from Smart Events — audit before you start
2. DDS authentication failures — test and monitor cloud storage connections
3. Attachment volume underestimation — calculate file counts before beginning
4. Multi-entity data separation — plan the LOCATIONID filter logic before loading to target

If your extraction is a one-time migration, budget extra time for attachment downloads, custom field mapping, and dimension-hierarchy reconstruction. If it's a recurring sync, invest early in delta-sync logic and transaction monitoring to avoid surprise overages.

At ClonePartner, we've built extraction pipelines from Sage Intacct for dozens of migrations and integrations. The pattern is always the same: DDS for the heavy lifting, API for the edge cases, and careful validation to make sure nothing gets left behind. If you're planning a migration out of Sage Intacct and want to avoid the pitfalls, we can help.