We made multiple updates to our auto-ledgering functionality to add robustness and improved accuracy to Ledger Transactions linked to payment objects. These updates include:
effective_at Ledger Transaction timestamp inheritance will now honor the originating bank's timezone.
effective_at for originated returns will now inherit the reconciled transaction's effective date/time upon posting.
Originated Returns against IPD's with linked Ledger Transactions will no longer be reversal Ledger Transactions, they will be independent Ledger Transactions representing the cancelling ledger impact of the original Ledger Transaction created from the IPD. This update helps support use cases in which the return is failed and needs to be retried.
✅ Reconciliation
Reconciliation Amounts on Expected Payments
Expected Payment API responses now include amount_reconciled and amount_unreconciled providing insight into the reconciliation status of a given Expected Payment. amount_reconciled, with its direction, represents the total amount that has been reconciled to the Expected Payment. amount_unreconciled, with its direction, is the amount that remains unreconciled for the Expected Payment.
Upcoming Changes
📚 Ledgers
GET Ledger Transactions and Ledger Accounts by External ID
We are expanding our GET endpoints for Ledger Transactions and Ledger Accounts to allow for retrieving resources by external_id. This update allows customers a more efficient pattern to retrieve Modern Treasury resources without needing to use Modern Treasury ID's.
💵 Payments
Enhanced Reporting for CRB Received Payments
Today, MT creates an Incoming Payment Detail when a CRB Wire is Returned. On December 8th, current customers on CRB will be migrated to the following new behavior:
MT will stop creating Incoming Payment Details for returned CRB Wires
MT will start creating Returns for returned CRB Wires, which will be linked to the originated Payment Order
IMAD/OMAD details will be added as Payment References to Received Wires and Returns at CRB
In addition, ACH Incoming Payment Details and Returns will now include ACH trace details as Payment References.
Within the Ledgers UI, customers now have the ability to specify the timezone they want to perform date/time filtering in. Timezones are set to the user's timezone setting by default, and can be accessed within all date/time filters within the Ledgers UI. Also included is the ability to the timestamp being used for date range filtering.
Ledgers Fund Flows UI Revamp
We've updated our T-Account view within the Fund Flows UI. Customers now have the ability to review the open balances of their Fund Flow for each included Ledger Account. We updated Ledger Account ordering to be alphabetical by default, and have refreshed the UX of the page.
The Ledgers sandbox now includes quickstart templates for common use cases to support developers getting up to speed on ledgering and payment flows. Each template is linked to an accompanying documentation guide outlining how to implement the solution.
Ledgers Fund Flows
With Ledgers Fund Flows customers can now visualize their end-to-end payment flows through metadata groupings. Each Fund Flow is dynamically created from pre-existing metadata key-value pairs, and allows you to review the ledger impact of every entry across the corresponding accounts. Fund Flows are available in the Ledgers UI under the ‘Fund Flows’ section.
Filter Ledger Transactions and Entries by Amount
Within the Ledgers UI and API, we now expose filters on Ledger Transaction and Ledger Entry objects by amount. The API filter is available on each object's LIST endpoint, and the UI filters are accessible through the corresponding UI table.
Revamped Create Ledger Transaction UI
We have updated our create Ledger Transaction form within the Ledgers UI. The new for provides a modernized UX while maintaining all core functionality. This release maintains the same functionality of the prior create Ledger Transaction form.
We released enhancements to our Ledger Account and Ledger Account Categories UI's, and have planned upcoming releases across Ledger and Platform.
Recently Released
📚 Ledgers
UI Balance Search by Date
Ledger Account and Ledger Account Category UI’s now have the ability to review their respective balances over a range of dates. After customers select a date range, they are able to review the Available Balance in the embedded chart or select the ‘Table’ option to review all balances over the chosen time frame.
Upcoming Changes
🧑💻 Platform
(Anticipated Release 8/18/2025)Reduced Data Retention for Request Logs Data retention for Request Logs searchable from the UI will be lowered from 4 months to 1 month. Request Logs older than 1 month will continue to be available via CSV export.
📚 Ledgers
UI Timezone Filters
All date filters in the Ledgers UI will have timezones as an option to select and edit. The timezone utilized will be considered when calculating balances and fetching Ledger Transactions or Ledger Entries.
Ledgers Sandbox Updates
Enhanced sandbox experience with embedded documentation, tutorials, and product guides to support your Ledgers exploration and enhance your testing experience.
We released several improvements to our payments and ledgers products including API, UI, and webhook updates.
Recently Released
💵 Payments
(Released 6/26/2025)Invoice support for custom issuer name: Customers can now create invoices with customized issuer names. The issuer name is shown on the hosted invoices page and invoice PDF exports. The issuer name can be set during creation through the invoicer_name field and defaults to the name of your Organization in Modern Treasury if not explicitly defined.
(Released 6/25/2025)Exposure of API Bank’s Internal Account ID: We have added a new vendor_id field to represent the ID assigned by API banks for a given account. You can use this ID in both the Internal Accounts API and the UI to assist in polling, since the field maps 1:1 with bank IDs.
📚 Ledgers
(Released 6/30/2025)Updated Filters on Ledgers UI:: We have updated the Ledgers UI to utilize standard modern filters. The updated filters provide a similar filter experience to the rest of the Modern Treasury app and provide customers with the ability to create Saved Views on their Ledgers UI’s.
(Released 6/23/2025)Ledger Account Webhooks:: We have added support for webhooks on Ledger Accounts. Customers can subscribe to receive webhooks over Ledger Account created or updated events. Ledger Accounts will send update webhooks for balance updates or changes to mutable fields (name, description, metadata, etc.).
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
💵 Payments
⭐️ Faster RTP Completion: We will change the signal used to trigger completion of instant payment rails (type = RTP) to the signal used today for the confirmed event (for PO webhooks). This means these Payment Orders with type RTP will have the confirmed and completed event at the same time.
This will ensure that Payment Order statuses match the instant settlement of these payments without changing reconciliation timeline.
⭐️ More Accurate Cross River Bank Wires Completion Timeline: Modern Treasury will change the trigger for completion of CRB wires to the signal used today for the confirmed event (for PO webhooks). Note that this means reconciliation of these payments will occur before the Payment Order status is moved to completed.
We made this change to account for CRB’s process of posting the wire transaction before confirming the wire will be processed and sent to the recipient.
Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
⭐️ External_idon Expected Payments : We will support a unique external_id field on Expected Payments, as we do on several objects.
Incoming Payment Detail<>Transaction Reconciliation Update : When an IPD and Transaction are reconciled, the IPD will always appear under a Transaction's Related Items, not Reconciled Items. This linkage will not mark the Transaction as reconciled or partially reconciled. Note that this change has already been applied to some users.
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
Creating LTs on Lock Failure: We plan to add an archive_on_lock_failure parameter on Ledger Transaction Creation. If a Ledger Transaction is created with this parameter and fails due to an insufficient balance, an archived Ledger Transaction will be created, recording the failure. This is useful for cases like card authorization to record failed authorizations.
External_idon Ledger Accounts : We will support a unique external_id field on Ledger Accounts, as we do on Ledger Transactions.
We released several improvements to our payments product, including payment actions for checks and NOC corrections objects for returns.
Recently Released
💵 Payments
(Released 6/20)Account Capabilities When Creating Internal Accounts at Cross River Bank: Users that create Internal Accounts using the API can now pass in an account_capabilities array to specify bank-issued identifiers themselves for different origination abilities.
(Released 6/20)Explicit Notification of Change (NOC) Corrections: In an effort to clarify to users what changes are a result of an ACH NOC return, we introduced a corrections object to Returns that includes all of the new, corrected information that was sent from the bank. We also now expose which receiving account a Return is linked to via receiving_entity_id and receiving_entity_type.
(Released 6/20)Payment Actions for Checks: You can now send guidance to your bank on how to process existing check payments via Modern Treasury, even if the check was printed by a third-party vendor. Today, Payment Actions supports Positive Pay and Stop Pay at select banks. If you are interested in adding Payment Actions support, please contact your CSM or Modern Treasury Account Manager.
(Released 6/20)Unverification of External Accounts via ACH Returns: If an ACH return is received on an ACH microdeposit credit or debit, we will now reset the verification status of that account to unverified. You can listen for this via the external_account.returned_verification webhook.
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
Export Permissions Update: Going forward, users will only have access to exports when they are the creator of the export or when they are assigned access to the report from which the export was created.
Dashboard Clean-Up: Redundant "Status Change" information will be removed from the dashboard, which appears in timeline views for various objects. Similar information can be found in "Events," which are in dashboard views, or retrieved via API and webhooks. Status changes will first be removed for Expected Payments and Payment Orders in November, with additional objects to follow in early 2025. Please contact Support if you have questions or concerns.
💵 Payments
⭐️ Faster RTP Completion: We will change the signal used to trigger completion of instant payment rails (type = RTP) to the signal used today for the confirmed event (for PO webhooks). This means these Payment Orders with type RTP will have the confirmed and completed event at the same time.
This will ensure that Payment Order statuses match the instant settlement of these payments without changing reconciliation timeline.
⭐️ More Accurate Cross River Bank Wires Completion Timeline: Modern Treasury will change the trigger for completion of CRB wires to the signal used today for the confirmed event (for PO webhooks). Note that this means reconciliation of these payments will occur before the Payment Order status is moved to completed.
We made this change to account for CRB’s process of posting the wire transaction before confirming the wire will be processed and sent to the recipient.
Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
⭐️ External_idon Expected Payments : We will support a unique external_id field on Expected Payments, as we do on several objects.
Incoming Payment Detail<>Transaction Reconciliation Update : When an IPD and Transaction are reconciled, the IPD will always appear under a Transaction's Related Items, not Reconciled Items. This linkage will not mark the Transaction as reconciled or partially reconciled. Note that this change has already been applied to some users.
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
In-App Journal Entry Builder: Users will be able to create journal entry exports in-app to export to ERPs. This feature is currently in development with design partners. If interested, reach out to your CSM.
Journal Entry Exports: Users will be able to create journal entries in the app to send to ERPs.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
Creating LTs on Lock Failure: We plan to add an archive_on_lock_failure parameter on Ledger Transaction Creation. If a Ledger Transaction is created with this parameter and fails due to an insufficient balance, an archived Ledger Transaction will be created, recording the failure. This is useful for cases like card authorization to record failed authorizations.
Waterfall Spend Logic: Users will be able to associate Ledger Account Categories with a ranked list of Ledger Accounts to pull funds from. If funds are pulled directly from these Categories, Modern Treasury will automatically draw down from each associated Ledger Account until it reaches zero.
Fund Flows: Users will be able to create custom groupings of Ledger Transactions to represent fund flows or end-to-end transactions. Fund flow views will be available in the Ledgers UI and will support the visualization of users' end-to-end payment workflow, including the individual Ledger Transactions and overall ledger impact of your fund flow.
External_idon Ledger Accounts : We will support a unique external_id field on Ledger Accounts, as we do on Ledger Transactions.
Check out this cycle's release notes for notable upcoming changes to MT's Ledgers product. As always, reach out to the team if you have any questions.
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
Export Permissions Update: Going forward, users will only have access to exports when they are the creator of the export or when they are assigned access to the report from which the export was created.
Dashboard Clean-Up: Redundant "Status Change" information will be removed from the dashboard, which appears in timeline views for various objects. Similar information can be found in "Events," which are in dashboard views, or retrieved via API and webhooks. Status changes will first be removed for Expected Payments and Payment Orders in November, with additional objects to follow in early 2025. Please contact Support if you have questions or concerns.
💵 Payments
Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
Incoming Payment Detail<> Transaction Reconciliation Update : When an IPD and Transaction are reconciled, the IPD will always appear under a Transaction's Related Items, not Reconciled Items. This linkage will not mark the Transaction as reconciled or partially reconciled. Note that this change was already applied to some users.
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
In-App Journal Entry Builder: Users will be able to create journal entry exports in-app to export to ERPs. This feature is currently in development with design partners. If interested, reach out to your CSM.
Journal Entry Exports: Users will be able to create journal entries in the app to send to ERPs.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
⭐️ Creating LTs on Lock Failure: We plan to add an archive_on_lock_failure parameter on Ledger Transaction Creation. If a Ledger Transaction is created with this parameter and fails due to an insufficient balance, an archived Ledger Transaction will be created, recording the failure. This is useful for cases like card authorization to record failed authorizations.
⭐️ Waterfall Spend Logic: Users will be able to associate Ledger Account Categories with a ranked list of Ledger Accounts to pull funds from. If funds are pulled directly from these Categories, Modern Treasury will automatically draw down from each associated Ledger Account until it reaches zero.
⭐️ Fund Flows: Users will be able to create custom groupings of Ledger Transactions to represent fund flows or end-to-end transactions. Fund flow views will be available in the Ledgers UI and will support the visualization of users' end-to-end payment workflow, including the individual Ledger Transactions and overall ledger impact of your fund flow.
⭐️ External_idon Ledger Accounts : We will support a unique external_id field on Ledger Accounts, as we do on Ledger Transactions.
We recently brought improvements to payment approvals, searching, and saved views. We are planning an update around how we reconcile Incoming Payment Details and Transactions.
Recently Released
🧑💻 Platform
(Released 5/21)Payment Approvals by API Key: Users can now create approval rules for payment orders based on the API Key used to create the payment order
💵 Payments
(Released 5/20)Invoice Search Improvements: Users can now search invoices on description and invoice number.
📚 Ledgers
(Released 5/21)Saved Views: Users can now create saved views of tables for routine or recurring reports, including filter sets, column selection and ordering.
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
Export Permissions Update: Going forward, users will only have access to exports when they are the creator of the export or when they are assigned access to the report from which the export was created.
Dashboard Clean-Up: Redundant "Status Change" information will be removed from the dashboard, which appears in timeline views for various objects. Similar information can be found in "Events," which are in dashboard views, or retrieved via API and webhooks. Status changes will first be removed for Expected Payments and Payment Orders in November, with additional objects to follow in early 2025. Please contact Support if you have questions or concerns.
💵 Payments
Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
⭐️ Incoming Payment Detail<> Transaction Reconciliation Update : When an IPD and Transaction are reconciled, the IPD will always appear under a Transaction's Related Items, not Reconciled Items. This linkage will not mark the Transaction as reconciled or partially reconciled. Note that this change was already applied to some users.
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
In-App Journal Entry Builder: Users will be able to create journal entry exports in-app to export to ERPs. This feature is currently in development with design partners. If interested, reach out to your CSM.
Journal Entry Exports: Users will be able to create journal entries in the app to send to ERPs.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
Unlinked Ledger Entry Details in Account Recon: When viewing historical account variance in the /reconciliation page, users will be able to see where variance is caused by Ledger Transactions that are not linked to payments. Users will be able to investigate by filtering to unlinked Entries on a given Ledger Account.
Linked Ledgerable Details in UI: When viewing a bank transaction, users will be able to see associated Ledger Transactions in the Related Items details. Users will also be able to see linked Ledger Transaction information on Payment Order and Expected Payment objects.
Historical Ledger Statements: Users will be able to generate statements that show a set of Ledger Account or Category balances for each day over a range of dates, to support MTL and other reporting use cases.
More Scalable LACs: Ledger Account Categories will support containing up to 10M Ledger Accounts and up to 7 levels of nesting.
Improved Account Recon View Performance: We will improve performance of the /reconcile page for organizations with large numbers of Expected Payments and Ledger Transactions.
Faster Ledger Queries: Performance improvements will enable faster querying of Ledger Account Category balances; categories with millions of accounts can be fetched in under 200ms.
Filter Enhancements: Users will be able to filter the Ledger Accounts page to view only accounts with nonzero posted balances. We will also fix an issue causing these filters to time out for some users.
Dashboard Design Update: We will update the design of filters and other pages in the dashboard for a cleaner, more intuitive experience.
Unledgered Amount Display: Users will be able to view the Unledgered Amount next to each bank transaction, showing any amount not yet recorded to the ledger.
Preset Payment Amounts: When ledgering a payment from the dashboard, the amount for both credit and debit entries will be preset to the payment amount.
Settlement ID Filter: Users will be able to filter Ledger Transactions in the dashboard by Settlement ID.
Currency Filter Fix: We will fix an issue on the Ledger Account page where a currency filter is ignored in search.
Dropdown Display Fix: We will fix an issue in which the Ledger Account Category dropdown persists on the screen when creating a Ledger Account.
Actions Button Fix: We will fix an issue where users can't access the actions button on Ledger Transactions table rows.
Recent releases include many-to-many reconciliation and faster imports and file payments at scale.
Recently Released
🧑💻 Platform
(Released 4/1)Multi-Factor Authentication Enabled by Default: As part of our phased rollout, MFA is now enabled by default for all newly created organizations that do not use SSO. This strengthens our security posture and helps ensure sensitive financial data remains protected. Existing organizations should continue working with their admins to complete their MFA migration ahead of the June 2025 enforcement deadline; details on migration tooling can be found here.
💵 Payments
(Released 4/30)Legal Entities at Increase: We now allow customers to programmatically create entities and attribute them to their Increase accounts. As part of this change, we will sunset the vendor_attributes[entity_id] key when creating Increase Internal Accounts and instead enable the ability to associate these Internal Accounts to Legal Entities by passing in a legal_entity_id.
(Released 5/1)Faster Imports at Scale: All importers now run significantly faster, improving ingestion speed, reliability, and reducing support escalations.
(Released 5/1)Triple Duplicate Payment Protection: File-based payments now have three layers of safeguards to prevent duplicate payments being sent.
(Released 5/1)Faster File Payments at Scale: System optimizations now support significantly higher throughput for large file-based payment volumes.
✅ Reconciliation
(Released in Early Access 5/9)Many-to-Many Reconciliation: Users can now manually reconcile many Transactions to many Expected Payments in the Reconcile side-by-side tool, enabling reconciliation for more complex payment scenarios. Some details to keep in mind regarding use of this feature:
Expected Payments that are included in many-to-many reconciliation must use exact amount (vs. amount range) and be reconciled wholly (vs. partially)
Transaction and Expected Payments groups must all have the same direction, either credit or debit
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
Export Permissions Update: Going forward, users will only have access to exports when they are the creator of the export or when they are assigned access to the report from which the export was created.
Dashboard Clean-Up: Redundant "Status Change" information will be removed from the dashboard, which appears in timeline views for various objects. Similar information can be found in "Events," which are in dashboard views, or retrieved via API and webhooks. Status changes will first be removed for Expected Payments and Payment Orders in November, with additional objects to follow in early 2025. Please contact Support if you have questions or concerns.
💵 Payments
⭐️ Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
In-App Journal Entry Builder: Users will be able to create journal entry exports in-app to export to ERPs. This feature is currently in development with design partners. If interested, reach out to your CSM.
Journal Entry Exports: Users will be able to create journal entries in the app to send to ERPs.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
Saved Reporting Views: Ops users will be able to navigate to a Financial Reporting view that will contain saved views of key operational balances, like MTL Reporting or Outstanding Liability balances. Saved views will be configured as subsets of your Ledger Account Category balances.
Unlinked Ledger Entry Details in Account Recon: When viewing historical account variance in the /reconciliation page, users will be able to see where variance is caused by Ledger Transactions that are not linked to payments. Users will be able to investigate by filtering to unlinked Entries on a given Ledger Account.
Linked Ledgerable Details in UI: When viewing a bank transaction, users will be able to see associated Ledger Transactions in the Related Items details. Users will also be able to see linked Ledger Transaction information on Payment Order and Expected Payment objects.
Historical Ledger Statements: Users will be able to generate statements that show a set of Ledger Account or Category balances for each day over a range of dates, to support MTL and other reporting use cases.
More Scalable LACs: Ledger Account Categories will support containing up to 10M Ledger Accounts and up to 7 levels of nesting.
Improved Account Recon View Performance: We will improve performance of the /reconcile page for organizations with large numbers of Expected Payments and Ledger Transactions.
Faster Ledger Queries: Performance improvements will enable faster querying of Ledger Account Category balances; categories with millions of accounts can be fetched in under 200ms.
Filter Enhancements: Users will be able to filter the Ledger Accounts page to view only accounts with nonzero posted balances. We will also fix an issue causing these filters to time out for some users.
Dashboard Design Update: We will update the design of filters and other pages in the dashboard for a cleaner, more intuitive experience.
Unledgered Amount Display: Users will be able to view the Unledgered Amount next to each bank transaction, showing any amount not yet recorded to the ledger.
Preset Payment Amounts: When ledgering a payment from the dashboard, the amount for both credit and debit entries will be preset to the payment amount.
Settlement ID Filter: Users will be able to filter Ledger Transactions in the dashboard by Settlement ID.
Currency Filter Fix: We will fix an issue on the Ledger Account page where a currency filter is ignored in search.
Dropdown Display Fix: We will fix an issue in which the Ledger Account Category dropdown persists on the screen when creating a Ledger Account.
Actions Button Fix: We will fix an issue where users can't access the actions button on Ledger Transactions table rows.
Recent updates include Saved Filters, Simplified Account Views and Multi-System Reconciliation.
Recently Released
🧑💻 Platform
(Released 3/31)Admin Approvals for Transaction Categorization Rules: Creating and editing categorization rules are now subject to admin approval. For more information on organization approvals, refer to our documentation here.
(Released 4/9)Saved Filters: Customers can now save and reuse filters in the UI across all tables.
(Released 4/17)Faster Search: We released broad improvements to search performance in parts of the app.
(Released 4/24)Bulk Results Archiving: We will now archive any bulk results that are older than one month.
💵 Payments
(Released 4/17)Account Verification Fallback: ACH fallback for account verification is now available for all customers when instant payment verification fails. We also added a webhook to notify customers when the fallback has been used (verification_fallback_used).
💵 ✅ Payments & Reconciliation
(Released 3/31)Simplified Account Views. We updated some dashboard pages to improve our in-app experience; please contact support if you have any questions.
We removed the Reconciliation Overview page; information on that page will be on the Cash Management page going forward.
We no longer surface metrics regarding inflows and outflows of cash. This information can still be found under Cash Management → Analytics.
Nested accounts are now accessible as a filter in Cash Management → Accounts.
✅ Reconciliation
(Released 4/22)Multi-System Reconciliation in App: We deployed a new page for users to link Expected Payments and Payment Orders using entity linking in the app. This feature allows users to map payments and payment intents across multiple systems. For more information, read our guide here.
(Released in Early Access 4/22)1-to-Many Reconciliation AI Suggestions: Users will receive suggestions for 1 Transaction to many Expected Payment reconciliation use cases, in addition to 1-to-1 suggestions that are available today.
Upcoming Changes
⭐️ indicates newly introduced upcoming changes
🧑💻 Platform
Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:
Reduced JAR Size: This change reduces the size of the SDK.
Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.
Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.
Export Permissions Update: Going forward, users will only have access to exports when they are the creator of the export or when they are assigned access to the report from which the export was created.
Dashboard Clean-Up: Redundant "Status Change" information will be removed from the dashboard, which appears in timeline views for various objects. Similar information can be found in "Events," which are in dashboard views, or retrieved via API and webhooks. Status changes will first be removed for Expected Payments and Payment Orders in November, with additional objects to follow in early 2025. Please contact Support if you have questions or concerns.
💵 Payments
Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.
Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.
Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.
Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.
Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.
Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.
Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.
Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.
Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.
Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.
New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.
✅ Reconciliation
Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.
In-App Journal Entry Builder: Users will be able to create journal entry exports in-app to export to ERPs. This feature is currently in development with design partners. If interested, reach out to your CSM.
Journal Entry Exports: Users will be able to create journal entries in the app to send to ERPs.
Many-to-Many Reconciliation: Users will be able to create rules to automatically reconcile many Transactions to many Expected Payments, enabling reconciliation for more complex payment scenarios.
Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.
📚 Ledgers
Saved Reporting Views: Ops users will be able to navigate to a Financial Reporting view that will contain saved views of key operational balances, like MTL Reporting or Outstanding Liability balances. Saved views will be configured as subsets of your Ledger Account Category balances.
Unlinked Ledger Entry Details in Account Recon: When viewing historical account variance in the /reconciliation page, users will be able to see where variance is caused by Ledger Transactions that are not linked to payments. Users will be able to investigate by filtering to unlinked Entries on a given Ledger Account.
Linked Ledgerable Details in UI: When viewing a bank transaction, users will be able to see associated Ledger Transactions in the Related Items details. Users will also be able to see linked Ledger Transaction information on Payment Order and Expected Payment objects.
Historical Ledger Statements: Users will be able to generate statements that show a set of Ledger Account or Category balances for each day over a range of dates, to support MTL and other reporting use cases.
More Scalable LACs: Ledger Account Categories will support containing up to 10M Ledger Accounts and up to 7 levels of nesting.
Improved Account Recon View Performance: We will improve performance of the /reconcile page for organizations with large numbers of Expected Payments and Ledger Transactions.
Faster Ledger Queries: Performance improvements will enable faster querying of Ledger Account Category balances; categories with millions of accounts can be fetched in under 200ms.
Filter Enhancements: Users will be able to filter the Ledger Accounts page to view only accounts with nonzero posted balances. We will also fix an issue causing these filters to time out for some users.
Dashboard Design Update: We will update the design of filters and other pages in the dashboard for a cleaner, more intuitive experience.
Unledgered Amount Display: Users will be able to view the Unledgered Amount next to each bank transaction, showing any amount not yet recorded to the ledger.
Preset Payment Amounts: When ledgering a payment from the dashboard, the amount for both credit and debit entries will be preset to the payment amount.
Settlement ID Filter: Users will be able to filter Ledger Transactions in the dashboard by Settlement ID.
Currency Filter Fix: We will fix an issue on the Ledger Account page where a currency filter is ignored in search.
Dropdown Display Fix: We will fix an issue in which the Ledger Account Category dropdown persists on the screen when creating a Ledger Account.
Actions Button Fix: We will fix an issue where users can't access the actions button on Ledger Transactions table rows.
