Looking for updates? We continue to release new objects and features using the REST API. Make sure to check out our REST API and the refreshed developer experience portal.

Looking for updates? We continue to release new objects and features using the REST API. Make sure to check out our REST API and the refreshed developer experience portal.

Looking for updates? We continue to release new objects and features using the REST API. Make sure to check out our REST API and the refreshed developer experience portal.

This release went live on August 8, 2025.

Accounts Receivable

Draft advances

AR advances can now be saved in a draft state. Saving an advance in a draft state allows you to complete and post the advance at a later time. This flexibility is helpful when an advance needs to be recorded, but cannot be completed until additional details are available. Use the STATE field to create and update draft advances. For more information, see:

• Create AR advance
• Update AR advance

New RECORDID field in AR advances

Starting with the 2025 R3 release, the Accounts Receivable configuration allows you to assign a document sequence to AR advances. When a document sequence is defined for advances in the Accounts Receivable configuration, a new RECORDID field in AR advance objects shows the unique payment ID for an advance. The new RECORDID field is included in XML API responses for read, lookup, and query functions, improving traceability.

For more information see About customer advances in the Sage Intacct Help Center.

Customer bank account and customer charge card to be deprecated

Sage Intacct is in the process of reducing the amount of cardholder data we manage. This initiative is a strategic move to minimize the auditing burden that comes with handling sensitive data. Implementing alternatives to card data storage and processing will streamline our internal operations while ensuring customer information remains secure. As part of this initiative, these legacy objects will be deprecated and unavailable for use starting in 2025 Release 4:

• Customer Bank Accounts
• Customer Charge Cards

Anyone using these legacy customer objects should plan for their deprecation. Theses objects and their supported operations will no longer be available after November 7, 2025.

Supply Chain Management transaction update behavior

Historically, updates to Supply Chain Management (OE/PO/Inv) transactions worked by deleting existing line item records and then re-adding them, treating every update like a new transaction. Starting with the R3 release, Sage Intacct intelligently updates line records for all companies. The benefits of this enhancement are:

• Existing line records are updated when needed, without the need for a new record number.
• Unneeded records are removed.
• Audit trail better reflects changes.

This change in update behavior improves efficiency by reducing unnecessary deletions and recreations. It also makes data management cleaner and minimizes the potential side effects from updates.

If you maintain integrations or custom processes around Supply Chain Management, keep this behavior change in mind. If you have questions or want to provide feedback, go to the Sage Intacct Developers Club.

Custom reports for transaction objects

When reading custom reports for Inventory, Order Entry, and Purchasing transactions in previous releases, the results included a DRILLRECORDNO field for each set of data returned in the report.

Starting with the 2025 R3 release, the DRILLRECORDNO field is no longer included for each set of data returned. Instead, the name of the field returned to identify each set of data is now dependent on the type of transaction, as follows:

• DRILLSORECORDNO (Order Entry)
• DRILLPORECORDNO (Purchasing)
• DRILLINVRECORDNO (Inventory Control)

Get object definition for AP bill and AR invoice

When using the lookup function to get an object definition for AP bill and AR invoice, the results include data about related transactions.

In previous releases, the RELATEDBY field showed that:

• An APBILL was related to a PODOCUMENT by a value of DESCRIPTION2
• An ARINVOICE was related to an SODOCUNMENT by a value of DESCRIPTION2

Starting with the 2025 R3 release, the value shown in the RELATEDBY field for both APBILL and ARINVOICE is DOCHDRKEY.

For example, this lookup request:

<lookup>
    <object>ARINVOICE</object>
</lookup>

Shows this relationship data in the results:

<Relationship>
<OBJECTPATH>PODOCUMENT</OBJECTPATH>
<OBJECTNAME>PODOCUMENT</OBJECTNAME>
<LABEL></LABEL>
<RELATIONSHIPTYPE>ONE2ONE</RELATIONSHIPTYPE>
<RELATEDBY>DOCHDRKEY</RELATEDBY>
</Relationship>

This release went live on May 9, 2025.

Create draft transactions without a document number

These changes apply to Inventory, Order Entry, and Purchasing legacy transactions.

When creating or updating legacy draft transactions in previous releases, the document number was required. This requirement was limiting for certain workflows because a document number cannot be changed after it is set and, by definition, draft transactions may not be well defined and ready for a static document number.

To make legacy draft transactions more flexible, starting with the 2025 R2 release you can:

• Create draft transactions without specifying a document number.
• Update a draft transaction using the record number.
• Update a draft transaction to add a document number.
• Get and delete transactions using their record number.

For more information about Inventory transactions, see:

• Create an Inventory Transaction (Legacy)
• Update an Inventory Transaction (Legacy)
• Delete an Inventory Transaction (Legacy)

For more information about Order Entry transactions, see:

• Create an Order Entry Transaction (Legacy)
• Update an Order Entry Transaction (Legacy)
• Delete an Order Entry Transaction (Legacy)

For more information about Purchasing transactions, see:

• Create a Purchasing Transaction (Legacy)
• Update a Purchasing Transaction (Legacy)
• Delete a Purchasing Transaction (Legacy)

Retrieve audit history without a document number

These changes apply to Inventory, Order Entry, and Purchasing legacy transactions.

Starting with the 2025 R2 release, you can retrieve the audit history for legacy transactions using the record number for the transaction instead of the document number. This change enables you to retrieve the history for all transactions, including draft transactions that may not yet have a document number assigned.

The following example shows how to retrieve the audit history for a Purchasing transaction using a record number instead of a document number:

<readByQuery>
    <object>AUDITHISTORY</object>
    <fields>*</fields>
    <query>OBJECTTYPE='podocument' and OBJECTKEY = '1165'</query>
    <pagesize>100</pagesize>
</readByQuery>

If you retrieve the audit history for a draft transaction that has not been assigned a document number, the response contains the record number in the OBJECTKEY field. If you retrieve the audit history for a transaction that has already been assigned a document number, the response contains the document number in the OBJECTKEY field. 

For more information about audit history, see Query and List Audit History (Legacy).

Purchasing

New HIDEPRICE field in transaction definitions

Starting with the 2025 R2 release, a new optional HIDEPRICE field is available in the Purchasing transaction definition (PODOCUMENTPARAMS) object.

Set this new HIDEPRICE field to true to allow users of the Sage Intacct Purchasing application to hide line item prices in transactions created from the transaction definition.

For more information, see the Accounting Properties in Create Purchasing Transaction Definition and Update Purchasing Transaction Definition in the API Reference.

New fields added for secondary vendor lien waivers

We added three fields to COMPLIANCERECORD to enable the use of lien waivers for secondary vendors:

• SECONDARYVENDORNAME: The name of the secondary vendor, if one is used. When a secondary vendor is used and a lien waiver is created for compliance purposes, the value of this field defaults to the secondary vendor name that appears on the primary document. Otherwise, this field can be null. You can override the value during an update call.
• SECONDARYVENDOR: Boolean field that indicates whether a lien waiver is generated for the secondary vendor for compliance purposes. When lien waivers are generated from the primary document, this field is set to true. Additionally, the secondary vendor compliance template is used when the printed document template for the compliance records is printed and emailed. You can override the value during an update call.
• SECVENDORCOMPLIANCETEMPLATE: A read-only field. Contains values from the COMPLIANCETYPE for the secondary vendor template.

For more information about compliance records, see Vendor Compliance Records.