File Size Limits and gzip Uploads
We defined new size limits for upload files:
MCP Server - New AI Skills
We’ve added new AI skills to our Fynapse Agent:
- Flow Builder - that allows you to turn your own transaction data into Fynapse Business Events with a Flow. This skill maps your transaction entity to Business Events, adds a script or routing step only where one is needed, previews the Flow with Fynapse until it is valid, and publishes it only when you confirm
- Subledger Configuration - that allows you to set up and change the accounting rules in Fynapse: how Business Events are identified, which accounts they post to, and how their Journals are built. The skill reads your current configuration, drafts the change, checks that it balances, validates it with Fynapse, and only then writes it, after you confirm. Where your approval workflow is on, changes go through it.
MCP Server - Configuration Capability
We’ve added new configuration REST APIs, plus matching tools on our MCP server so your AI agent (for example, Claude) can call them directly. We’ve also released a Fynapse configuration skill. They guide the agent through building and changing your configuration properly: it reads what’s already set up, proposes changes for you to review, and validates them before anything is applied.
Validations Screen Redesign
We migrated the Validations screen for an improved look and feel.
List of changes:
- the Download button moved from the Actions column to the Name column, next to the name of the Entity
- the Go to Details button moved from the Details column to the Actions column
- the Details column was removed
- on the Details screen, if the validation includes a name of an Entity, the name is a link that will now redirect you to the Data Structure Definition Details screen for this Entity, instead of Finance Data Service
Extraction Configuration - Invalid Status
We introduced a new Invalid status for extract configurations.
The Invalid status is assigned to an extraction configuration when:
- an Entity that was used as the source for the extraction has been deleted
- attributes from an Entity were deleted that are required by the extraction
Processing Summary Overhaul
We redesigned the Processing Summary screen and added a second view, Pipeline, that follows each ingestion through the stages it actually passes, including the Flows that read its records.
The changes are listed below.
The classic view keeps its columns, statuses and counts.
Adjustment Portal Enhancement
We introduced a number of enhancements on the Adjustment Portal screen.
Previously, when uploading a file with Journals, there were two ingestion error scenarios:
- The file had invalid format or header - the file would receive Invalid upload status, no records were ingested and you had to download the errors in a .CSV file
- The records in the file were invalid - the file would receive Invalid upload status, the records were ingested but failed processing; you had to download the errors in a .CSV file
Reclassification Enhancement
We enhanced the Reclassification functionality. You now have two reclassification methods available:
- Sweep method - this method covers how reclassification worked up to date, where adjustments of multiple Accounts are reclassified and posted to one offset Account based on a set of filtering condition defined for the source Accounts
- Net position method - new method for reclassification, where reclassification is based on the signage of the total sum balance for a selected asset and liability Account pair or pairs specified within the rule
- if upon the calculation the total sum is negative, the transactions are moved from Accounts defined as asset Accounts to Accounts defined as liability Accounts
- if upon the calculation the total sum is positive, the transactions are moved from Accounts defined as liability Accounts to Accounts defined as asset Accounts
Flow Screens Redesign
We redesigned the Flow screens. Please consult the sections below to see itemised lists of changes of the affected screens.
The way you build, validate and submit Flows hasn’t changed.
Reclassification Enhancement
We enhanced the reclassification screen with the following changes:
-
Process date - allows you to set the date for which Journals created as the result of the reclassification process will be posted.
This can be either the current business date or a specific date.
Please note that the Process date is calculated based on the time zone of the Subledger Node/Accounting Base combination assigned to the reclassification configuration used for the reclassification run.
-
Show logs - a new button that allows you to view detailed logs for reclassification runs.
Zero Value Transactions
Fynapse rejects financial data with a transaction amount of zero by default. The new Zero value transactions setting on the System Settings screen changes that behaviour: zero value transactions become valid financial data that produces balanced Journals, posted to the Subledger and queryable alongside every other Journal.
Business Events with zero amounts generate Journals only through Posting Patterns whose Amount Signage is set to
AUTO, and zero value Journals contribute nothing to Balances. The setting is included in Configuration Data, so
it travels with configuration downloads and uploads.
Work with Fynapse using AI
We added a new For AI Agents area to the Fynapse documentation. It brings together the resources you need to connect AI tools to Fynapse, give them access to Fynapse product knowledge, and equip them with reusable skills for finance-specific tasks.
The new area includes guidance for the Fynapse MCP Server, Documentation MCP Server, and Agent Skills, including skills for Flux Analysis, Journal Search, and Journal Explainer.
Period Locking - Approval Workflow
We enhanced the Period Locking screen to be compatible with Approval Workflow functionality. Now you can create workflow configurations, with hierarchical approval process, for actions on the Period Locking screen.
Please note that Approval Workflow has one additional key feature on the Period Locking screen. Due to the unique specification of the screen’s functionality, i.e. when you request an approval to open a period you specify a timeframe it should be open. Because the Approver may take a while to approve the request, they specify the time a period should be open. It can be either the timeframe specified by the requestor, e.g. 2 days, or a different timeframe selected by the approver, e.g. 3 days. In both instances the period is open since the time the request is approved, and NOT from the time the request has been submitted.