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.
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:
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
2024 Release 2 2024-04-15
This release went live on May 10, 2024.
Accounts Receivable
Receive draft payments
Starting with the 2024 R2 release, users with appropriate permissions can create, edit, and delete Accounts Receivable payments in a draft state using the XML API or the Sage Intacct user interface. Draft payment functionality provides more control, flexibility, and accuracy when managing payments, especially when working with bulk payments and imports. Draft payments save time and reduce errors because they allow you to make changes before finalizing payments rather than reversing those payments. When draft payments are finalized, you can submit those payments for processing.
To create a draft payment, you must have Accounts Receivable – Manage payments - Add permissions. To submit a draft payment for processing, you must have Accounts Receivable – Manage payments – Post permissions.
- To create Accounts Receivable payments in draft state, specify Draft in the new ACTION parameter as described in Create AR Payment.
- When draft payments are finalized, update and submit those payments by specifying Submit in the new ACTION parameter as described in Update AR Payment.
You can only update a payment that is in Draft state (D). If a payment has been submitted and is Complete (C), it cannot be updated. You can update a draft payment to change header information or revise payment details. For more information about updates and the details to include for each type of update, see Update AR Payment.
You can also delete payments that are in Draft state (D). To learn more, see Delete AR Payment.
Value of state field for existing AR payments
With the introduction of draft payments, as discussed in the preceding release note, the state field for existing completed payments will be changed from null (blank) to a value of C in the weeks following the 2024 R2 release.
Get invoices - allocations affect read results
When you issue requests to read invoices as described in Get Invoice, the responses to those requests will no longer include the DEPT or LOCATION fields for invoice items that involve allocations to distribute amounts to those dimensions. This is due to a change in how split General Ledger entries are handled for transaction allocations.
If the transaction that an invoice item represents does not involve allocations to department or location, there is no change in the fields returned for the read response. Additionally, if an allocation rule allocates to only one of these dimensions, then only that field is omitted from the read response. For example, if a rule allocates to location and project, the DEPT field is returned in the read response for an invoice, but the LOCATION field is not.
Taxes
Capture payment tax (France only)
A new field that captures payment tax for a transaction line item has been added to both Purchase Order and Order Entry legacy transactions. This new field applies only to French companies and entities. If you set the new paymenttaxcapture
field to true
when you create or update an Order Entry or Purchasing transaction, the VAT tax record for that transaction line item is generated when the transaction line is paid.
For more information, see:
create_potransaction.potransitems.potransitem
update_potransaction.updatepotransitems.updatepotransitem
create_sotransaction.sotransitems.sotransitem
update_sotransaction.updatesotransitems.updatesotransitem
Purchasing
Add notes and project information in vendor compliance records
You can now include a note in and associate a project with a compliance record. Store information related to purchase orders and subcontract primary documents, and access everything from the record. When available, the project is retrieved via PROJECTID
from the primary document header.
NOTE: To enable the Vendor Compliance subscription, first enable Accounts Payable, Purchasing, and Construction. Vendor compliance is available only for Construction at this time.
We added four new fields for this feature, but only PROJECTID
and NOTES
have user-supplied values. The other two fields are read-only.
NOTES
- Text field for user-added notes. Use 4000 or fewer characters.PROJECTKEY
- Foreign key reference to the project table.PROJECTID
- Unique user-defined project identifier. Should refer to an existing, active project record or, on updates, an active or inactive one. The project is retrieved from the primary document header.PROJECTNAME
- The project name, which is derived from thePROJECTKEY
field.
For more information, see:
Inventory
Default conversion type for items
Starting with the 2024 R2 release, non-inventory type items included in transaction workflows can be converted by price or quantity. To take advantage of this capability, the following configuration options must be enabled for Order Entry and Purchasing:
- Enable price conversion
- Enable override on transaction conversion type
With the preceding configuration options enabled, you can use the new DEFAULT_CONVERSIONTYPE
field to specify the conversion type for non-inventory items. Non-inventory items can be converted by price or by quantity. This new field is supported for 3.0 XML API create
and update
item functions. To learn more, see:
Customization Services
List Smart Event Log Records (Legacy) to be discontinued
We want to let you know about a change that’s coming later this year: The smarteventlog
object and get_list
will be discontinued. For R2, you can continue to use the object. Users will be able to obtain Smart Event audit information by using a report based on the Audit Trail and adding it to an application menu for easy access. Learn more here: Use an Audit History report.
Construction
Line-level tax schedule assignment
Customers who use Advanced Tax, Multi-tax with VAT, or custom VAT can now assign tax schedules to individual document entry lines in both Purchase Order documents and Order Entry documents.
- The new option to “Enable override of tax schedule on document entry” must be enabled in Purchasing and Order Entry configuration.
- The
TAXSCHEDULEID
inPODOCUMENTENTRY
andSODOCUMENTENTRY
can be set to the ID of the tax schedule to apply to that line. If no value is supplied for this field, the tax schedule is assigned based on the tax schedule map logic as in previous releases. - The
TAXSCHEDULEID
field is a read-only field unless the new configuration option is enabled. - This option doesn’t apply to Simple Tax or to Avalara.
Accounts Payable
Get bills - allocations affect read results
When you issue requests to read bills as described in Get Bill, the responses to those requests will not include the DEPT or LOCATION fields for bill items that involve allocations to distribute amounts to those dimensions. This is due to a change in how split General Ledger entries are handled for transaction allocations.
If the transaction that a bill item represents does not involve allocations to department or location, there is no change in the fields returned for the read response. Additionally, if an allocation rule allocates to only one of these dimensions, then only that field is omitted from the read response. For example, if a rule allocates to location and project, the DEPT field is returned in the read response for a bill, but the LOCATION field is not.
2024 Release 1 2024-01-20
This release went live on the evening of February 16, 2024.
Construction
Enable reverse conversions for non-inventory line items in Order Entry
Only those companies with Construction subscriptions have access to the options to enable reverse conversions. For more information about subscribing to Construction functionality, see Configure Construction.
Use new fields to enable reverse conversions for non-inventory line items in order entry transactions. When reverse conversions are enabled, you can reduce the net amount previously converted for a transaction line item. You can use reverse conversion amounts when creating a transaction (using <create_sotransaction>
) or updating a transaction (using <update_sotransaction>
) by setting the <reverseconversion>
field to true for a transaction line item (<sodocumententry>
).
When the <reverseconversion>
field is set to true, downstream conversions for that transaction line item must include an amount using the opposite sign (positive or negative) of the upstream document. In addition, when set to true, the <reverseconversion>
field requires that the conversion for that line item be the opposite of the upstream document. For example, let’s say that on an OE order, you:
- enter a line for 100 units
- convert 50 units
- determine that the original conversion should be 25.
You can convert the order again to add a negative 25 (-25) units for the original converted line of 50. This conversion corrects the original converted unit amount from 50 to 25 and creates the downstream invoice with a credit for that line to the customer.
In addition, when reverse conversions are enabled for Order Entry, several new read-only fields are calculated and returned in <SODOCUMENTENTRY>
and <SODOCUMENT>
query and list responses:
<reversepriceconverted>
<reverseqtyconverted>
<stdpriceconverted>
<stdqtyconverted>
<sourcedocid>
<sourcedoclineid>
For more information, see:
Accounts Receivable
Starting with the 2024 R1 release, several changes have been made to the fields and information provided when you use the get_companyprefs
function to list Accounts Receivable (AR) preferences.
All AR selectable preferences have a new property exposed that holds the record number. The following example shows the new value for the overpayment account preference:
<companypref>
<application>AR</application>
<preference>OVERPAYMENTKEY</preference>
<prefvalue>336</prefvalue>
</companypref>
The preference value, <prefvalue>
, for all General Ledger accounts previously included both the account number and account name. Now only the account number for General Ledger accounts is returned as shown in the following example:
<companypref>
<application>AR</application>
<preference>RO_ACCOUNT</preference>
<prefvalue>7502</prefvalue>
</companypref>
The preference value, <prefvalue>
, for all General Ledger journals previously included both the journal symbol and name. Now only the journal symbol is returned as shown in the following example:
<companypref>
<application>AR</application>
<preference>RI_JOURNAL_A</preference>
<prefvalue>BAJ</prefvalue>
</companypref>
In previous releases, the Aging setup was returned with the name and a single set of preference values like so:
<companypref>
<application>AR</application>
<preference>AGP01</preference>
<prefvalue>0-30, 31-60</prefvalue>
</companypref>
Now several objects are returned to represent the Aging setup, including the name, record number, module key, and more, as shown in the following example:
<companypref>
<application>AR</application>
<preference>AGINGSETUP.RECORDNO</preference>
<prefvalue>1</prefvalue>
</companypref>
<companypref>
<application>AR</application>
<preference>AGINGSETUP.MODULEKEY</preference>
<prefvalue>0-30, 31-60</prefvalue>
</companypref>
For more information about the get_companyprefs
function, see List Subscription Preferences.
Purchasing
Option not to generate Lien waivers in Vendor Compliance Definitions
The Vendor Compliance feature continues to offer more flexibility. A lien waiver is a document between two parties that states payment is made for work performed or material supplied. You might not want lien waivers with negative amounts, though. Use the new Vendor Compliance Definition field, ALLOWNEGATIVELIENWAIVERS
, to indicate your preference.
When using create
or update
, use true
(default) to indicate that lien waivers can be generated with negative amounts, otherwise use false
. This value only affects the generation of future lien waiver compliance records and applies when CATEGORY
is set to ‘Lien waiver’. If CATEGORY
is not set to ‘Lien waiver’ and a value is supplied, an error is returned.
Track Insurance and Miscellaneous compliance records by either Primary document or Vendor.
With this release, you can use a Primary document to track Insurance and Miscellaneous compliance records. Previously, you could only track Insurance and Miscellaneous compliance records by Vendor. The Vendor Compliance Definition’s TRACKBY
field description has been updated to reflect this change.
NOTE: To enable the Vendor Compliance subscription, first enable Accounts Payable, Purchasing, and Construction. Vendor compliance is available only for Construction at this time.
For more information, see:
Project Contracts
Project Contract Billing enhancements
New fields have been added to the Accounts Receivable invoice object (ARINVOICE
) for better integration with project contract billing:
EXTERNALREFNO
- An external reference numberPC_DESCRIPTION
- A description for the contractCONTRACTDATE
- Contract dateARCHITECTKEY
- Unique identifier for the architectARCHITECT
- ArchitectBILLTHROUGHDATE
- Billing through dateBILLAPPLICATIONNO
- Billing application number
Contracts
Renewal dates in contract object
A recent release added read-only fields for renewal dates to both the CONTRACT
and CONTRACTDETAIL
objects.
- For the
CONTRACT
object, the new field isCN_RENEWAL_DATE
- For the
CONTRACTDETAIL
object, the new field isCN_LINE_RENEWAL_DATE
2023 Release 4 2023-10-14
This release went live on the evening of November 10, 2023.
Accounts Payable
Recall bills
Starting with the 2023 R4 release, submitted AP bills can be recalled using a new recallApBill
function. This new function provides a more flexible approval workflow for bills. Now when a bill is submitted and not yet approved or declined, if changes are required due to an error or new information, you can recall the bill, make the necessary updates, and then re-submit the bill.
To successfully recall a bill:
- The bill must be in Submitted state.
- The user must have Edit permission for the bill.
When a bill is successfully recalled:
- The bill’s state changes from Submitted to Draft.
- The bill is removed from the Approval History table in the Sage Intacct UI.
- Approvers are notified via email that the bill has been recalled.
- Because the recalled bill is in Draft state, any users with edit permissions can update and resubmit the bill.
Note that there are no restrictions on the number of times a bill in Submitted state can be recalled.
To learn more about the new recallApBill
function, see Recall Bill.
Vendor approvals
Vendor approvals can now be managed using the XML API. Vendor approval adds controls to your vendor creation and update workflow, requiring approval before new and updated vendors can be used in Accounts Payable and Purchasing transactions.
When vendor approval is enabled, existing vendors are automatically approved. From that point on, new and edited vendors are submitted to the Approve Vendor queue after they are created or revised. Designated approvers review the vendor records and either approve or decline them.
The read-only STATE
field in the VENDOR
object shows the approval state of the vendor. Possible values are:
S
- SubmittedA
- ApprovedR
- Rejected/Declined
Several new functions have been added to the XML API to support vendor approvals, including: getVendorsToApprove
, approveVendor
, declineVendor
, and getVendorApprovalHistory
. After setting up vendor approval, you can use these new functions to manage approvals. For more information, see Vendor Approvals.
The new getVendorApprovalHistory
function returns data about each approval for a specific vendor. That data includes information such as the date that the vendor was approved, whether the vendor is new or was updated, who created or updated the vendor, and who approved the vendor.
For more information about vendor approvals, see these topics in the Sage Intacct Help Center:
Error message generated when applied credits fail
In previous releases, credits used to pay bills were not applied when:
- A multi-entity company was configured to: Limit AP credits to the entity owners.
- The location ID for a credit and the location ID for a bill did not match.
For example, if a credit existed with the LOCATIONID
set to San Diego and you attempted to pay two outstanding bill items with that single credit, one with the LOCATIONID
set to San Diego and the other with the LOCATIONID
set to Atlanta, only the bill item with the San Diego location was paid. And, no error was generated to notify you that the other bill item was not paid.
Now in these scenarios, if location IDs do not match, an error message is generated to notify you that: Payments include one or more credits that are restricted to a different location.
Accounts Receivable
Sage Intacct to change value of state field for existing AR payments
To support an upcoming Accounts Receivable enhancement, Sage Intacct plans to update the STATE
field for existing ARPYMT
and legacy ARPAYMENT
objects with record types of ro
(applied AR overpayment) and rp
(overpayment). In early 2024, Sage Intacct will change the STATE
field for existing ARPYMT
and legacy ARPAYMENT
objects from a null value to a value of C
. The new C
value indicates that these existing AR payments are confirmed.
Company
Global transaction security setup
A new AFRSETUP
object lets you configure Global Transaction Security, which can be set to prevent users from editing, deleting, or reclassifying transactions posted to the General Ledger. Companies with multiple entities can configure this security at the entity level.
For more information see:
Consolidation
Run consolidations in companies that are multi-tiered or have entities that are partially owned
Beginning with the 2023 R4 release, you can use new ownership structure objects and ownership structure entity objects. The new objects enable companies with multi-tiers or those that are partially owned entities (or both) to run consolidations that reflect the complexity of their companies.
Let’s say that you purchase or sell an entity during a specific period. You can edit your ownership structure to reflect this change. For example, you can include a new entity purchased in February of 2020 in its relevant ownership structure. Consolidations will then include the new entity as of February 2020.
After defining an ownership structure, you can run consolidations for the ownership structure per period. For each consolidation, you can specify a reporting period. Then, you can convert the base currencies used by different entities into a designated base currency for the consolidated data. To learn more about ownership structures, see Ownership Structure workflow.
For more information, see:
Contracts
Recognize sales revenue on contract line invoice
A new field in the contractdetail
object allows you to control whether revenue recognition for a contract line is deferred or recognized when the line is posted. When the REV_REC_ON_INVOICE
field is set to true, Intacct automatically assigns the “Recognize on revenue” revenue template to both revenue journals. This template indicates there’s no revenue schedule or requirement for the user to post revenue separately.
Later when the contract line is invoiced, Intacct automatically posts the revenue. The contract line’s journal balances will only display unbilled, billed, and paid values for sales revenue and Accounts Receivable.
General Ledger
Option to include period balance details in account balances
You can use the new showperiodbalancedetail
option in get_accountbalancesbydimensions
requests to obtain details as well as balances. Details in the response include bifurcation of credit, debit, adj-credit, and adj-debit values. The sum of the periodbalancedetail
amounts will equal the periodbalance
amount.
- See
get_accountbalancesbydimensions
for more information.
Inventory
Identify if a kit is enabled for a contract in Items
A kit item is associated with two or more kit component items. Kit component items are the individual products or services that could be sold alone or included in product bundles.
In 2023 R2, we added an enhancement. You can identify when kits are enabled for contracts using the CONTRACTENABLED
field for Items. This field is only available for items with the ITEMTYPE
field set to kit
. When set to true
, the item must adhere to restrictions for the kit.
In addition, the ITEMID
field in Contract Lines now includes contract-enabled kit items.
For more information, see:
Miscellaneous
3rd row in addresses
All objects that contain mailing addresses now have an optional address3
field to contain a 3rd row of address information when needed. Affected objects are:
Purchasing
Purchasing and Order Entry transactions (Construction only)
New fields show taxable amounts after deduction of retainage
For Construction customers using a VAT or GST tax solution, two new read-only fields in the PODOCUMENTENTRY
and SODOCUMENTENTRY
objects show taxable amounts after deduction of any retainage held for a Construction contract. The new read-only fields are:
EXTENDEDPRICENETRETAINAGE
- Shows the taxable amount after deduction of retainage held:TRX_VALUE
-TRX_AMOUNTRETAINED
.EXTENDEDBASEPRICENETRETAINAGE
- Shows the base taxable amount after deduction of retainage held:UIVALUE
-AMOUNTRETAINED
.
For more information about Construction contracts and retainage, see these topics in the Sage Intacct Help Center:
Lien waiver option is now available in Vendor Compliance
In the previous release, we introduced the Vendor Compliance feature, which allows you to define compliance requirements and types for your vendors. We enhanced the feature and added a lien waiver category to compliance definitions. This enhancement impacts the following objects.
NOTE: To enable the Vendor Compliance subscription, first enable Accounts Payable, Purchasing, and Construction. Vendor compliance is available only for Construction at this time.
Vendor Compliance Definitions
We added three new fields:
GENERATEFOREACH
- Indicates whether to generate rules forAP Bill
orAP payment
. Applies only whenCATEGORY
isLien waiver
. IfCATEGORY
is set toLien waiver
, then a value must be supplied inGENERATEFOREACH
.MINLIENWWAIVERAMOUNT
- Indicates the minimum amount required for a lien waiver to generate. Applies only whenCATEGORY
isLien waiver
.MINPRIMARYDOCAMOUNT
- Indicates the minimum amount required for a primary document to generate. Applies only whenCATEGORY
isLien waiver
.
We made the following changes to the existing Vendor Compliance Definition fields:
CATEGORY
-Lien waiver
is now an option.TRACKBY
-PrimaryDoc
is now an option whenCATEGORY
isLien waiver
.VALIDATIONRULE
-Document received
is now an option whenCATEGORY
isLien waiver
.GENERATERULE
- Now in use to indicate whether to automatically generate compliance records and how to do so when they are generated.COMPDEFENTRIES
- Now in use. Options are:VENDTYPENAME
- The vendor type name to use whenTRACKBY
is set toVendor
.DOCPARID
The transaction definition to use whenTRACKBY
is set toLien waiver
.
The create
and update
functions include the new fields and new values for existing fields. The delete
function is not affected by the Vendor Compliance Definition updates.
The read
, readbyname
, query
, readbyquery
, and lookup
responses now include the new fields and new values for existing fields.
Vendor Compliance Types
We added two new fields:
COMPLIANCETEMPLATE
- Used when the compliance category is Lien waiver. The document template for printing compliance records.FINALCOMPLIANCETEMPLATE
- Used when the compliance category is Lien waiver. The document template for printing final compliance records.
The create
, update
, and delete
functions are not affected by the Vendor Compliance Type updates.
The read
, readbyname
, query
, readbyquery
, and lookup
responses now include the new fields.
Vendor Compliance Records
We added 38 new fields:
NOTE: Only FINALCOMPLIANCE
and SENDTOCONTACTNAME
have user-supplied values. The rest of the new fields are read-only.
VENDORNAME
- The vendor name related to the compliance record.DOCPARID
- The ID to relate this record to Purchasing.PRIMARYDOCKEY
- The primary document key that relates the record to the Vendor Compliance Definition viaTRACKBY
ifCATEGORY
isLien waiver
.PRIMARYDOCID
- The primary document ID that relates the record to the Vendor Compliance Definition viaTRACKBY
ifCATEGORY
isLien waiver
.APBILLNO
- TheAPBILL
number to associate to a record. Note that Lien waivers are voided automatically if an AP bill is deleted.APBILLKEY
- TheAPBILL
key to associate the record to a bill.APPAYMENTKEY
- TheAPPAYMENT
key to associate the record to a payment.COMPLIANCETEMPLATE
- The printed document template used for this record ifCATEGORY
isLien waiver
. Records created from the compliance type are prefilled with the selected templates.FINALCOMPLIANCETEMPLATE
- TheFINALCOMPLIANCETEMPLATE
selected in Vendor Compliance Types ifCATEGORY
isLien waiver
.VOIDED
- Boolean to indicate whether the record is void. Options aretrue
orfalse
(default).FINALCOMPLIANCE
- Boolean to indicate whether the compliance record is finalized. Options aretrue
orfalse
(default).SENDTOCONTACTKEY
- The key that relates the record to the contact recipient of the docs.SENDTOCONTACTNAME
- The contact name associated with the record and related toSENDTOCONTACTKEY
.RECEIVEDBYNAME
- The name of the employee who received the compliance record.
COMPLIANCESENDTO
:
EMAIL1
- The primary email address to send compliance-related lien waiver correspondence to.EMAIL2
- The secondary email address to send compliance-related lien waiver correspondence to.FIRSTNAME
- The first name of the contact to send compliance-related lien waver correspondence to.LASTNAME
- The last name of the contact to send compliance-related lien waver correspondence to.CONTACTNAME
- The contact name.PREFIX
- The prefix to use for the contact.INITIAL
- The contact name middle initial.COMPANYNAME
- The company name to use for the contact.PRINTAS
- Print as.PHONE1
- Primary phone number to use for the contact.PHONE2
- Secondary phone number to use for the contact.CELLPHONE
- Cellular phone number to use for the contact.PAGER
- Pager number to use for the contact.FAX
- Fax number to use for the contact.URL1
- The primary URL to use for the contact.URL2
- The secondary URL to use for the contact.VISIBLE
- Indicates whether the contact mailing and email information are visible.
COMPLIANCESENDTO.MAILADDRESS
ADDRESS1
- Address line 1 of the contact.ADDRESS2
- Address line 2 of the contact.CITY
- City of the contact.STATE
- State of the contact.ZIP
- Zip/postal code of the contact.COUNTRY
- Country of the contact.COUNTRYCODE
- Country code of the contact.
We also made the following changes to existing Vendor Compliance Record fields:
CATEGORY
-Lien waiver
can now be returned as an option.
The delete
function is not affected by the Vendor Compliance Record updates.
The create
function returns an error if fields applicable to lien waivers have values when CATEGORY
is not Lien waiver
.
The update
function returns an error if fields applicable to lien waivers have values when CATEGORY
is not Lien waiver
. The call can optionally contain FINALCOMPLIANCE
and SENDTOCONTACTNAME
.
The read
, readbyname
, query
, readbyquery
, and lookup
responses now include the new fields and new values for existing fields.
For more information, see: