2025 Release 3 2025-08-01
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:
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:
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.
New returned fields and changes to some returned values for foreign currency payments
Starting in 2025 R4, when a bill or invoice is paid using a foreign currency bank, new fields and different values in some existing fields will be returned on query and lookup functions for Accounts Payable and Accounts Receivable payment objects.
All objects that currently return these fields on query and lookup will be affected when a bill or invoice is paid using a foreign currency bank: TRX_TOTALENTERED, TRX_AMOUNT, and CURRENCY.
Anyone paying bills or invoices using a foreign currency bank should plan for these changes.
Header-level payment objects
When a bill or invoice is paid using a foreign currency bank for header-level payment objects like APPYMT and ARPYMT, query and lookup functions return new fields and different values for some existing fields, as follows.
Currently:
- CURRENCY field - Foreign currency is returned
- TRX_TOTALENTERED field - Amount paid by bank is returned
After R4:
- New BANKCURRENCY field - Foreign currency is returned
- New BANKTRXAMOUNT field - Amount paid by bank is returned
- CURRENCY field - Base currency is returned
- TRX_TOTALENTERED field - Transaction amount of bill/invoice is returned
Line-level payment objects
When a bill or invoice is paid using a foreign currency bank for line-level payment objects like APPYMTDETAIL and ARPYMTDETAIL, query and lookup functions return new fields and different values for some existing fields, as follows.
Currently:
- CURRENCY field - Foreign currency is returned
- TRX_AMOUNT field - Amount paid by bank is returned
After R4:
- New BANKCURRENCY field - Foreign currency is returned
- New BANKTRXAMOUNT field - Amount paid by bank is returned
- CURRENCY field - Base currency is returned
- TRX_AMOUNT field - Transaction amount of bill/invoice is returned
You can submit questions about these changes in 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>
2025 Release 2 2025-04-14
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 totrue
. 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 theCOMPLIANCETYPE
for the secondary vendor template.
For more information about compliance records, see Vendor Compliance Records.
2025 Release 1 2025-01-19
This release went live on February 7, 2025.
Accounts Payable
The following changes are being introduced for the VENDOR and VENDORVISIBILITY objects. To learn more about the functions that are changing, see Vendors in the XML API Reference.
VENDOR read function
- In previous releases, by default the legacy read function returned a value of null for the visibility_type field. Starting with the 2025 R1 release, the legacy read function returns a value of
Restricted
,Unrestricted
, orRootOnly
for the visibility_type field to report the actual setting for this field. - In previous releases, by default the read function returned a value of null for the OBJECTRESTRICTION field. Starting with the 2025 R1 release, the read operation returns a value of
Restricted
,Unrestricted
, orRootOnly
for the OBJECTRESTRICTION field to report the actual setting for this field.
VENDOR lookup function
The data returned for the OBJECTRESTRICTION field has changed:
- In previous releases, the value returned for the
<LABEL>
property was null. Starting with 2025 R1, the value returned for the<LABEL>
property isVisibility
. - In previous releases, the value returned for the
<DESCRIPTION>
property was null. Starting with 2025 R1, the value returned for the<DESCRIPTION>
property isVisibility
. - In previous releases, the value returned for the
<DATATYPE>
property wasTEXT
. Starting with 2025 R1, the value returned for the<DATATYPE>
property isENUM
.
VENDORVISIBILITY read function
Starting in the 2025 R1 release:
- The RESTRICTEDLOCATIONS and RESTRICTEDDEPARTMENTS fields are being removed from entity objects and moved to owned objects of each entity.
- Several new fields have been added to capture data about owning entities, including MEGAENTITYKEY, MEGAENTITYID, and MEGAENTITYNAME.
Accounts Receivable
Customer bank account to be deprecated
As part of the initiative to minimize the auditing burden that comes with handling sensitive data, the legacy customer bank account object will be deprecated and unavailable for use starting in 2025 Release 4.
Anyone using the legacy customer bank account object should plan for its deprecation. The object and all its supported operations, documented in the Customer Bank Accounts API reference content, will no longer be available after November 7, 2025.
Customer and customer visibility objects
The following changes are being introduced for the CUSTOMER and CUSTOMERVISIBILITY objects. To learn more about the functions that are changing, see Customers in the XML API Reference.
CUSTOMER read function
- In previous releases, by default the legacy read function returned a value of null for the visibility_type field. Starting with the 2025 R1 release, the legacy read function returns a value of
Restricted
,Unrestricted
, orRootOnly
for the visibility_type field to report the actual setting for this field. - In previous releases, by default the read function returned a value of null for the OBJECTRESTRICTION field. Starting with the 2025 R1 release, the read operation returns a value of
Restricted
,Unrestricted
, orRootOnly
for the OBJECTRESTRICTION field to report the actual setting for this field.
CUSTOMER lookup function
The data returned for the OBJECTRESTRICTION field has changed:
- In previous releases, the value returned for the
<LABEL>
property was null. Starting with 2025 R1, the value returned for the<LABEL>
property isVisibility
. - In previous releases, the value returned for the
<DESCRIPTION>
property was null. Starting with 2025 R1, the value returned for the<DESCRIPTION>
property isVisibility
. - In previous releases, the value returned for the
<DATATYPE>
property was TEXT. Starting with 2025 R1, the value returned for the<DATATYPE>
property isENUM
.
CUSTOMERVISIBILITY lookup function
Starting in the 2025 R1 release:
- The RESTRICTEDLOCATIONS and RESTRICTEDDEPARTMENTS fields are being removed from entity objects and moved to owned objects of each entity.
- Several new fields have been added to capture data about owning entities, including MEGAENTITYKEY, MEGAENTITYID, and MEGAENTITYNAME.
CUSTOMERVISIBILITY read function
Starting in the 2025 R1 release:
- The RESTRICTEDLOCATIONS and RESTRICTEDDEPARTMENTS fields are no longer returned with this function.
- A new MEGAENTITYNAME field is returned with this function.
Cash Management
New fund transfers fields - Early adopter enhanced currency support
For global companies configured to use enhanced currency support, which is available for early adopters in the 2025 R1 release, the following new fields are returned in results for FUNDSTRANSFER lookup
and read
functions. Note that the new Enable Multi-Currency Funds Transfer feature flag must be enabled to use enhanced currency support.
FROM_ACCOUNT_TRX_AMOUNT
FROM_ACCOUNT_BASE_CURRENCY
FROM_ACCOUNT_AMOUNT
FROM_ACCOUNT_EXCH_RATE_TYPE_ID
FROM_ACCOUNT_EXCHANGE_RATE
FROM_ACCOUNT_EXCH_RATE_DATE
For more information about the FUNDSTRANSFER object, see Fund Transfers in the API Reference.
Purchasing
Use custom fields for compliance objects
Custom fields give you a way to capture business-specific data. Compliance types provide a way to specify which custom fields are applicable to the type of compliance record used. Now when you query on the COMPLIANCETYPE
object, you can see a COMPLIANCERECORDCUSTOMFIELDS
field. For example:
<query>
<object>COMPLIANCETYPE</object>
<select>
<field>RECORDNO</field>
<field>COMPLIANCETYPEID</field>
<field>NAME</field>
<field>STATUS</field>
<field>COMPLIANCERECORDCUSTOMFIELDS</field>
</select>
<filter>
<equalto>
<field>STATUS</field>
<value>active</value>
</equalto>
</filter>
</query>
The COMPLIANCERECORD
object remains unchanged. Note that custom fields must be added to compliance records through the user interface before being used by compliance types. From the main menu in your company, go to Platform Services or Customization Services > All > Custom Fields to add custom fields to compliance records. Expected behaviors, such as errors returned when required custom fields are not included, apply. In addition:
- The
delete
function is not affected by this change. - The
read
,readbyname
,query
,readbyquery
,lookup
, andinspect
functions now includeCOMPLIANCERECORDCUSTOMFIELDS
.
For more information, see Vendor Compliance Types.
Construction
Specify entities as limited
The ENTITY
object has a new ISLIMITEDENTITY
Boolean field. The field is included in read and query responses. The default value is false.
Web Services
RECORDTYPE capitalization change
The capitalization of the RECORDTYPE
value for some record types has been changed slightly. For example, the previous value of AR Advance
is now returned as AR advance
. This is the list of new record type values:
Quick invoice
AR invoice
AP bill
AR advance
AR discount
AR receipts
AR adjustments
AR realized multi-currency gain/loss
AP adjustment
Permission enhancement for AUDITHISTORY
and ADVAUDITHISTORY
Permission requirements for the use of the AUDITHISTORY
and ADVAUDITHISTORY
objects in the API have been changed to match the requirements of the equivalent Audit Trail and Advanced Audit Trail features in the application. The user associated with the API session must have View permission for custom reports. That permission can be enabled under the Platform Services subscription.
Audit-related requests when the user does not have the right permission will return this error:
Unable to view audit history. You do not have permission to view audit history
2024 Release 4 2024-10-14
This release went live on November 8, 2024.
Platform Services
Labels for custom objects and custom fields support different locales
To define a custom field using XML, you use <label>
. Now you can use a new tag, <customLabels>
, to add labels for different locales. Nest <customLabels>
under the custom object or custom field for which to define locales. Then, define a <customLabel>
using the <locale>
and <text>
tags. In this example, <customLabels>
is used to define two locales: US English and French.
<customField>
<customFieldId>CF_ID_1</customFieldId>
<type>checkbox</type>
<ownerObject>vendor</ownerObject>
<customLabels>
<customLabel>
<locale>en-US.UTF-8</locale>
<text>Preacquisition vendor</text>
</customLabel>
<customLabel>
<locale>fr-FR.UTF-8</locale>
<text>vendeur de préacquisition</text>
</customLabel>
</customLabels>
...
If you include both <label>
and <customLabels>
, then <label>
defines the company’s locale.
For more information, see Customization Packages.
Accounts Receivable
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, the legacy customer charge card object will be deprecated and unavailable for use starting in 2025 Release 1. Anyone using the customer charge card object should plan for its deprecation. The object and all its supported operations, documented in the Customer Charge Cards API reference content, will no longer be available after February 7, 2025.
Now bill to and contact tax IDs available in Invoices
Two new read-only fields now appear in ARINVOICE
responses: BILLTO.TAXID
and CONTACT.TAXID
. This change means that the tax identification information for the bill to and contact objects is available within the invoice itself.
Accounts Payable
Vendor Payments powered by American Express are being retired
On December 31, 2024, the following American Express payment services will no longer be available in Sage Intacct:
- American Express ACH Payment Service
- American Express Card Payment Service
Make sure to process all payments by December 20, 2024 to avoid any potential issues. For more payment provider options, visit the Sage Intacct Marketplace.
Update vendor bank file details
Starting with the 2024 R4 release, if you want to update bank file details for a vendor, you must supply the record number of those details in the update request. For example, to successfully update United Kingdom (GB) bank file details, issue a request as shown in the following example:
<update>
<VENDOR>
<RECORDNO>59</RECORDNO>
<VENDORID>GBVendor</VENDORID>
<VENDORBANKFILEDETAILS>
<vendorbankfiledetail>
<RECORDNO>65</RECORDNO>
<BSBNUMBER>123-456</BSBNUMBER>
<BANKACCOUNTNUMBER>53423347</BANKACCOUNTNUMBER>
<ACCOUNTNAME>sunheel</ACCOUNTNAME>
<SORTCODE></SORTCODE>
</vendorbankfiledetail>
</VENDORBANKFILEDETAILS>
</VENDOR>
</update>
For more information, see Update Vendor in the API Reference.
Contracts
New fields added to Contract object
New fields have been added to the CONTRACT
object to support the contract dimension, which is available to companies with Order Entry Revenue Management. The contract dimension is used to categorize, track, and analyze Order Entry transactions without a subscription to the Contracts application. To learn more about the contract dimension, see Track Order Entry transactions with the contract dimension in the Sage Intacct Help Center.
The fields added to the CONTRACT
object include:
APPLICATION
- Specifies whether the contract is a full contract or dimension-only.ADDITIONALCONTACTNAME
- Identifies an additional contact.
For more information about these new fields,see Create Contract.
New fields added to track service periods
To support the inclusion of service period start date and service period end date in the Contracts workflow, new optional fields have been added to several objects. These updates ensure that service period information is retained throughout the workflow, from the contract phase to invoice generation. These new fields are available to companies with the Contracts and Platform Services subscriptions. To learn more about this update, see “Service periods” in the 2024 R4 Sage Intacct Release Notes.
CONTRACTBILLINGSCHEDULEENTRY
SERVICEPERIODSTARTDATE
- Identifies the start date of a billed service period in the billing schedule.SERVICEPERIODENDDATE
- Identifies the end date of a billed service period in the billing schedule.
CONTRACTUSAGE
SERVICEPERIODSTARTDATE
- Identifies the start date of a billed service period based on usage. When used, the service period start date should be the first day of the month ofUSAGEDATE
. For example, ifUSAGEDATE
falls anytime in September, 2024, thenSERVICEPERIODSTARTDATE
should be 09/01/2024.SERVICEPERIODENDDATE
- Identifies the end date of a billed service period based on usage. When used, the service period should be the last day of the month ofUSAGEDATE
. For example, ifUSAGEDATE
falls anytime in September, 2024, thenSERVICEPERIODENDDATE
should be 09/30/2024.
GENINVOICEPREVIEW
SERVICEPERIODSTARTDATE
- Identifies the start date of a billed service period in a contract invoice preview. Not used whenSERVICEPERIODOVERRIDEOPTION
is set to “Do not override”.SERVICEPERIODENDDATE
- Identifies the end date of a billed service period in a contract invoice preview. Not used whenSERVICEPERIODOVERRIDEOPTION
is set to “Do not override”.SERVICEPERIODOVERRIDEOPTION
- Indicates whetherSERVICEPERIODSTARTDATE
andSERVICEPERIODENDDATE
in the invoice lines that come from aCONTRACTBILLINGSCHEDULEENTRY
orCONTRACTUSAGE
record are overridden. Valid options are:Do not override
- Indicates that the values inSERVICEPERIODSTARTDATE
andSERVICEPERIODENDDATE
fromCONTRACTBILLINGSCHEDULEENTRY
orCONTRACTUSAGE
are used to generate the invoice preview.Override empty dates only
- When used, include values forSERVICEPERIODSTARTDATE
andSERVICEPERIODENDDATE
, which override null values used inCONTRACTBILLINGSCHEDULEENTRY
orCONTRACTUSAGE
.Override all dates
- When used, include values forSERVICEPERIODSTARTDATE
andSERVICEPERIODENDDATE
, which override all values inCONTRACTBILLINGSCHEDULEENTRY
orCONTRACTUSAGE
.
GENINVOICEPREVIEWLINE
SERVICEPERIODSTARTDATE
- Identifies the start date of a billed service period in an invoice line based on values inCONTRACTBILLINGSCHEDULEENTRY
,CONTRACTUSAGE
, orGENINVOICEPREVIEW
. Read only.SERVICEPERIODENDDATE
- Identifies the end date of a billed service period in an invoice line based on values inCONTRACTBILLINGSCHEDULEENTRY
,CONTRACTUSAGE
, orGENINVOICEPREVIEW
. Read only.
SODOCUMENTENTRY
In addition to the contract object changes, order entry transactions will now return the new fields:
SERVICEPERIODSTARTDATE
- Identifies the start date of a billed service period in an invoice line.SERVICEPERIODENDDATE
- Identifies the end date of a billed service period in an invoice line.
For more information about these new fields, see:
Construction
New fields added for tracking the scope and schedule of a project
These new fields are available to companies with Construction and Projects subscriptions.
New fields have been added to the PROJECTS
object to track project scope and schedule details. Because the details are within the PROJECTS
object, details such as scope and terms are always available. To learn more about this update, see “Scope and schedule of a project” in the 2024 R4 Sage Intacct Release Notes.
SCOPE
- Expected scope of the work for the project.INCLUSIONS
- Inclusions as part of the project.EXCLUSIONS
- Exclusions as part of the project.TERMS
- Terms of the project.SCHEDULEDSTARTDATE
- Scheduled start date of the project in format mm/dd/yyyy.ACTUALSTARTDATE
- Actual start date of the project in format mm/dd/yyyy.SCHEDULEDCOMPLETIONDATE
- Scheduled completion date in format mm/dd/yyyy.REVISEDCOMPLETIONDATE
- Revised completion date in format mm/dd/yyyy.SUBSTANTIALCOMPLETIONDATE
- Substantial completion date in format mm/dd/yyyy.ACTUALCOMPLETIONDATE
- Actual completion date in format mm/dd/yyyy.NOTICETOPROCEED
- Date of notice to proceed in format mm/dd/yyyy.RESPONSEDUE
- Date that the response for the project is due in format mm/dd/yyyy.EXECUTEDON
- Date that the project is executed on in format mm/dd/yyyy.SCHEDULEIMPACT
- Description of the impact of the project on the schedule.
For more information, see Projects.
Order Entry
Override individual tax line items if you use Advanced tax
Customers who use Advanced Tax can now override individual tax lines; previously, if Advanced Tax was enabled for a company, individual tax lines could not be overridden. The fields to override a tax line are trx_tax
and overridedetailid
used in linesubtotal
. If trx_tax
is not provided for the line, the VAT is calculated using the percentage value set in overridedetailid
.
For more information, see Order Entry Transactions.
Projects
Retainage now supported with Projects subscription
Retainage is a portion of a contracted price that is intentionally withheld until a project is substantially complete. In previous releases, retainage fields were supported only with a Construction subscription. Starting with this release, XML API retainage fields are supported with either a Purchasing subscription or a Construction subscription. Affected retainage objects and fields include:
CUSTOMER
:RETAINAGEPERCENTAGE
VENDOR
:RETAINAGEPERCENTAGE
SODOCUMENT
:RETAINAGEPERCENTAGE
,TRX_AMOUNTRETAINED
,PREVIOUSRETAINAGEBALANCE
,RETCOMPLETEDAMT
,RETSTOREDMATERIALS
, andISRETAINAGERELEASE
POTRANSACTION
:RETAINAGEPERCENTAGE
,TRX_AMOUNTRETAINED
PODOCUMENTPARAMS
:ENABLE_RETAINAGE
For more information, see:
- Customers
- Vendors
- Order Entry Transactions
- Purchasing Transactions
- Purchasing Transaction Definitions
2024 Release 3 2024-07-15
This release went live on August 9, 2024.
Accounts Receivable
New AR invoice fields identify original transaction documents
Sage Intacct applications provide customizable workflows that enables users to set up various transaction definitions according to their business needs. When creating a workflow, users can configure multiple potential entry and exit points. This flexibility can make it cumbersome to identify:
- The source document in the conversion workflow
- The lines associated with the final child document
To improve visibility into document conversions, the 2024 R3 release includes several new fields that are returned in read request results for the AR invoice (ARINVOICE
) object. These new fields are returned for invoice objects that reference a transaction in Order Entry. The new fields include:
ORIGDOCKEY
- Record number of the originating document in the workflow conversion.ORIGDOCLINEKEY
- Record number of the line item in the originating document in the workflow conversion.ORIGDOCID
- ID of the originating document in the workflow conversion.ORIGDOCLINEID
- ID of the line item in the originating document in the workflow conversion.
Apply custom discounts to received payments
Starting with the 2024 R3 release, users can apply custom discounts to an invoice when receiving a payment. Custom discounts streamline the process of applying a discount because, unlike existing term discounts, they don’t require that you first create an AR term that includes the discount details. The flexibility of custom discounts allows you to dynamically adjust a discount when you receive payment.
To activate custom discounts, go to the Accounts Receivable settings and select the option named Enable custom discounts. When this Accounts Receivable setting is enabled, you can use the new TRX_TOTALDISCOUNTTOAPPLY parameter to apply a custom discount in the payment details when creating a new payment or updating a draft payment.
Note the following restrictions for custom discounts:
- Custom discounts and term discounts cannot be combined for the same invoice.
- When a custom discount is applied to an invoice, term discounts cannot be used for subsequent payments on that same invoice.
- You can apply custom discounts in combination with a cash or credit payment, but discounts alone are not allowed.
- You cannot apply a custom discount that is equal to the total amount of the invoice.
Because custom discounts and term discounts cannot be combined, do not include a DISCOUNTDATE in AR payment details when using the TRX_TOTALDISCOUNTTOAPPLY parameter. If you provide a value for both DISCOUNTDATE and TRX_TOTALDISCOUNTTOAPPLY in the payment details, the request to create the payment fails.
For more information, see Create AR Payment and Update AR Payment.
Change in behavior for term discounts
In addition to the introduction of custom discounts, term discount behavior has also been changed. Now if you provide two or more discount dates for separate invoice lines in the payment details of a payment request, the payment request will fail. In the past when multiple discount dates were provided in the payment details, the first discount date supplied in the request was used and any additional dates were ignored. Starting with this release, that behavior has been changed so that only one discount date is expected and any additional dates provided cause the payment request to fail with an error.
Accounts Payable
New AP bill fields identify original transaction documents
Sage Intacct applications provide customizable workflows that enable users to set up various transaction definitions according to their business needs. When creating a workflow, users can configure multiple potential entry and exit points. This flexibility can make it cumbersome to identify:
- The source document in the conversion workflow
- The lines associated with the final child document
To improve visibility into document conversions, the 2024 R3 release includes several new fields that are returned in read request results for the AP bill (APBILL
) object. These new fields are returned for bill objects that reference a transaction in Purchasing. The new fields include:
ORIGDOCKEY
- Record number of the originating document in the workflow conversion.ORIGDOCLINEKEY
- Record number of the line item in the originating document in the workflow conversion.ORIGDOCID
- ID of the originating document in the workflow conversion.ORIGDOCLINEID
- ID of the line item in the originating document in the workflow conversion.
AP adjustment line item fields no longer supported
When creating or updating an AP adjustment using the legacy create_apadjustment
or update_apadjustment
function, note that two lineitem
fields are no longer supported:
totalpaid
totaldue
If you include these fields in the line items of a create_apadjustment
or update_apadjustment
request, the provided values are ignored.
Unapply credit-only payments
Starting with the 2024 R3 release, you can unapply credit-only payments using the legacy reverse_appayment
function. When reversing a credit-only payment, supply the record number of the credit-only payment and the date that the payment should be reversed. For more information, see Reverse AP Payment (Legacy).
Changes in behavior for credit-only payments
In addition to the ability to unapply credit-only payments, there are several changes in behavior for credit-only payments, including:
- If you issue a request to create a credit-only payment with
ACH
as the payment method, the payment request succeeds regardless of whether ACH payments are configured for your company. - If an invalid payment method is included in your request to create a credit-only payment, the payment request fails. For a credit-only payment, the payment method can be omitted or can be a valid value. In cases where the payment method is omitted, the default AP payment method from the company’s configuration is used.
- If an invalid financial entity is included in your request to create a credit-only payment, the payment request fails. For a credit-only payment, the financial entity can be omitted or can be a valid value.
- When you issue a request to create a credit-only payment, the response now includes a record number (
RECORNO
). - If your company is configured to use the Intacct Daily exchange rate, you issue a request to create a credit-only foreign currency payment, and you supply a future payment date in the request, the payment fails. You must change the date to the current or an earlier date so that the Intacct Daily exchange rate is known.
Changes in behavior for payments
The following changes have been implemented for AP payments in this release:
- If you issue a request to create a payment and you attempt to apply an inline credit from a bill that has an unpaid balance to a different bill, the payment request fails. You cannot apply inline credits from a bill that has a remaining positive balance.
- If you issue a request to create a payment and specify a charge card ID for the financial entity (
FINANCIALENTITY
), but do not provide a corresponding payment method (PAYMENTMETHOD
), the request fails.
New status field for payment provider method
When you read a payment provider method object, PROVIDERPAYMENTMETHOD
, a new status
field is returned to indicate whether the method is active or inactive. To learn more about reading this object, see Get Payment Provider Payment Method.
Purchasing
New transaction detail fields identify original transaction documents
Sage Intacct applications provide customizable workflows that enable users to set up various transaction definitions according to their business needs. When creating a workflow, users can configure multiple potential entry and exit points. This flexibility can make it cumbersome to identify:
- The source document in the conversion workflow
- The lines associated with the final child document
To improve visibility into document conversions, the 2024 R3 release includes several new fields that are returned in read request results for the Purchasing transaction (PODOCUMENT
) and Order Entry transaction (SODOCUMENT
) objects. The new fields include:
ORIGDOCKEY
- Record number of the originating document in the workflow conversion.ORIGDOCLINEKEY
- Record number of the line item in the originating document in the workflow conversion.ORIGDOCID
- ID of the originating document in the workflow conversion.ORIGDOCLINEID
- ID of the line item in the originating document in the workflow conversion.
Upcoming revision to draft transaction definition validation
In an upcoming release, changes will be implemented so that validations on draft transaction definitions occur when a transaction posts rather than when a transaction is created. These changes will allow users to create draft transaction definitions that contain minimal information to act as placeholders for accounting transactions. Performing transaction validation when a transaction posts rather than when it is created will improve workflow automation by allowing users to match draft placeholder transactions to incoming purchasing documents.
All transaction definitions, Order Entry, Purchasing, and Inventory Control, will be updated to support creation of draft documents without validation. More details about these planned changes will be provided in future release notes.
Construction
New joint checks and joint payees
In construction and some other fields, companies hire subcontractors to work on part or all of their projects. In some cases, the subcontractor that is hired also hires their own subcontractors to complete the contracted work. In these cases, joint checks can be issued for a primary vendor (subcontractor) and their secondary vendor (the subcontractor’s subcontractor). This ensures that the secondary subcontractor is paid for their work and can help avoid unnecessary churn and possible liens against projects by unpaid secondary vendors.
A new Joint Payee object (APBILLJOINTPAYEE
) lets you define joint payees and associate them with specific AP bills. When paying a bill that has associated joint payees, you can create separate payment detail objects for each payee as needed, such as for the primary vendor and each secondary vendor.
For more details, see the page on the new Joint Payee object.
Other objects that have been updated to support joint checks:
- New value for the
PAYMENTMETHOD
field:Joint Check
- New read-only fields:
JOINTPAYEENAME
,JOINTPAYEEPRINTAS
- New field to select a joint payee:
JOINTPAYEEPRINTAS
- New read-only field:
JOINTPAYEENAME
- New read-only fields:
JOINTPAYEENAME
,JOINTPAYEEPRINTAS
New user type for construction managers
You can now create, update, or query for a construction manager user type in the Users
object’s USERTYPE
field. The construction manager user type tracks Sage Construction Management (CM) and Intacct Construction usage without impacting the project manager user type.
NOTE: Available only with a subscription to Construction.
For more information, see:
Purchasing multi-document conversion
When creating a purchasing transaction you can now specify a source document to convert from at the line level instead of at the transaction level. You can specify different source documents and source document lines for each transaction line in the purchasing transaction, allowing you to convert from multiple documents in a single transaction.
Valid conversions must conform to these rules:
- The purchasing transaction being created must have the same vendor ID as the source documents.
- Conversion must be allowed by the specified transaction definition.
- Source documents must be in a valid document state that allows conversions, typically Pending or Partially Converted.
- The source documents must use the same currency as the current downstream document.
- The source documents must belong to the same entity as the purchasing transaction.
- Fully converted lines can be included in a multi-document conversion if the quantity or amount to convert is set to 0.
For more information, see the sourcedocid
and sourcedoclineid
fields at the bottom of the potransitem
table on the Purchasing Transactions page.
Item is now optional when creating a project change order
The ITEMID
field has been made optional when creating a project change order, and it can be deleted when updating a change order. It must point to an active, non-inventory item for billing.
For more information, see Project Change Orders.
Construction tax enhancements
These read-only tax-related fields have been added to order entry transaction line objects (SODOCUMENTENTRY
) and purchasing transaction line objects (PODOCUMENTENTRY
):
PERCENTVAL
- The aggregated tax rate for all the tax details assigned to a lineTAXABSVAL
- The aggregated tax amount for all the tax details assigned to a lineLINETOTAL
- The sum of extended transaction price plus tax amountTRX_LINETOTAL
- Transaction totals amount for the lineTAXABLEAMOUNT
- Taxable amount of the lineEXTENDEDPRICENETRETAINAGE
- Extended transaction price net retainageEXTENDEDBASEPRICENETRETAINAGE
- Extended base price net retainage