Istoricul incidentelor Floqast

We are currently investigating reports of errors when refreshing reconciliations and uploading files for customers using our Egnyte integration.

The issue has been identified and a fix is being implemented.

We have released a fix for this issue, and customers using Egnyte should no longer be experiencing these errors. We are continuing to monitor to ensure stability, and a Root Cause Analysis will be shared here when available.

We are currently investigating reports of "Something Went Wrong" errors when loading pages in the application. For any affected customers, clearing your web browser's cache should allow you to access the application while our engineers address the underlying issue.

We have identified the cause of the issue and are working on a fix.

A fix has been released for this issue, and customers should no longer receive these "Something Went Wrong" errors. If you continue to receive the error, refreshing your browser will resolve it. We will continue to monitor, and a Root Cause Analysis will be posted here once available.

**Summary:** On May 19, 2026, some customers on our US database experienced "Something Went Wrong" errors when attempting to access the FloQast platform. Affected customers were able to restore access by clearing their browser cache. The issue was fully resolved on May 20. **Root Cause:** A recent update to how the platform routes login and authentication requests introduced a misconfiguration in the network path. Under the new routing, certain browser security checks received an unexpected redirect response, which browsers are required to reject per web standards. Once a browser encountered this error, it cached the failure, meaning subsequent requests by the same user continued to fail until the browser cache was cleared. **Immediate Resolution:** The network routing configuration was corrected so that authentication requests reach the intended destination without triggering the redirect. The fix prevents recurrence of the caching problem going forward. **Follow-up Actions:** Additional controls are being put in place to allow the team to respond more quickly to issues with future rollouts, limiting customer impact while investigations are underway. The production deployment pipeline is also being strengthened with additional safeguards to ensure rollback procedures work as expected when needed.

We are currently investigating reports of Trial Balance files not being successfully processed after being sent via the FloQast Connect SFTP server for customers on our APAC database.

We have released a fix for this issue, and Trial Balances uploaded via the FloQast Connect SFTP server are now being successfully processed again. We will continue to monitor and will share a Root Cause Analysis here when it is available.

**Summary:** Between 10:23 AM PT on May 15, 2026, and 4:50 PM PT on May 18, 2026, customers on the APAC database were unable to upload Trial Balance and Chart of Accounts files via the FloQast Connect SFTP server. **Root Cause:** A software update to an internal file-processing component introduced a new configuration requirement that had not been applied to the APAC database environment. As a result, the service was unable to construct the correct address for its internal file handling system, causing all upload attempts to fail. **Immediate Resolution:** The missing configuration was identified and applied to the affected environment, restoring normal upload functionality. Successful file transfers were confirmed shortly thereafter. **Follow-up Actions:** The team is conducting a broader audit to ensure configuration standards are consistently applied across all service environments and databases. Additional safeguards are being added to the deployment process so that configuration requirements introduced by software updates are validated across all affected services before they reach production.

We are currently investigating an issue affecting Request Agent. Users attempting to access the Request Agent dashboard page may find the page loading endlessly.

We are continuing to investigate this issue.

The issue has been identified and a fix is being implemented.

A fix has been applied to the US and EU databases and both are operating normally. We are continuing to work on restoring full functionality for the AU database. We will provide a further update once AU has been resolved.

This incident has been resolved.

**Summary:** On May 12, 2026, between 10:46 AM PT and approximately 1:15 PT, the Request Agent feature was unavailable. Functionality was restored for customers on our US database at approximately 1:15 PT, for customers on our EU database at approximately 1:24 PT, and for customers on our APAC database by 1:55 PT. Customers were unable to create or view Requests, and customers were also unable to create Evidence Requests in Compliance Management. **Root Cause:** This incident was caused by an error introduced during a routine infrastructure update that resulted in certain services becoming misconfigured when deployed to production, making the Request Agent feature unavailable. **Immediate Resolution:** The misconfiguration was identified, and the affected services were restored to a known-good state, returning full functionality across all regions. **Follow-up Actions:** The deployment pipeline has been updated so that the affected class of services now always builds fresh from environment-specific configuration rather than reusing previously packaged artifacts, preventing this category of misconfiguration from reaching production. Traffic routing configuration is being audited across environments to ensure priority values are consistent and changes are validated before reaching production. The team is also accelerating the migration of affected legacy services to a more modern hosting model that eliminates this class of packaging issue entirely.

We are aware of an issue causing an "Something Went Wrong" error for users attempting to access FloQast. Users may be unable to load the application or see an unexpected error on login. Our engineering team has been alerted and is actively investigating.

We are continuing to investigate this issue. We have identified that this issue is isolated to our US region. Customers in the AU and EU regions have been confirmed as fully operational.

A fix has been deployed for the issue affecting US customers. We are actively monitoring to confirm full stability.

We are continuing to monitor for any further issues.

This incident has been fully resolved. US customers can access FloQast as normal. A Root Cause Analysis will be published on this page shortly. We apologize for the disruption and thank you for your patience.

**Summary:** On May 11, 2026, between 3:08 PM and 3:48 PM PT, all customers using the US production environment were unable to log in or access the application. Customers on the EU and APAC databases were not affected. **Root Cause:** A recent deployment introduced a change to how the application constructs the web addresses used to communicate with its backend services. Due to a difference in how those addresses are formatted in the US environment compared to other regions, requests were being sent to an incorrect path, which prevented authentication and page access from completing successfully. **Immediate Resolution:** The address construction logic was corrected, and the fix was deployed, restoring full access for all affected customers shortly thereafter. **Follow-up Actions:** We are broadening automated test coverage to exercise environment-specific configuration more thoroughly, so this class of issue can be caught before reaching production. Additional monitoring and alerting are being added to detect access failures earlier. We are also working toward greater consistency in how service addresses are defined across our production environments to reduce the risk of environment-specific regressions going forward.

We are currently investigating an issue affecting AutoRec Matching. Users are able to upload transaction files successfully, however uploaded transactions are not appearing for matching. Additionally, clients with NetSuite connected accounts are experiencing failures when pulling transactions or 'user is currently matching' messages. We are actively investigating and will provide updates as they become available.

We are continuing to investigate this issue.

The issue affecting transaction syncing has been resolved. Transactions should now be pulling in as expected for all connected clients. If you continue to experience any issues, please contact our support team.

**Summary:** Beginning at approximately 12:50 PM PT on May 7th, customers using the AutoRec Matching module were unable to upload transaction files or sync data from NetSuite. Uploads failed without clear error messages, and NetSuite sync jobs appeared to stall without completing. Upload functionality was restored at 8:38 AM PT on May 8th, and NetSuite sync functionality was restored at approximately 1:40 PM PT. **Root Cause:** While resolving a separate platform issue, a routine redeployment of several background services caused two of them to load incompatible versions of a shared software component. **Immediate Resolution:** Both services were restored to their correct configurations, resolving file upload and NetSuite sync failures across all production regions. A backlog of jobs that had stalled during the incident was also cleared manually, allowing them to complete successfully. **Follow-up Actions:** The team is putting in place more rigorous validation steps around service redeployments to catch configuration mismatches earlier. Additional monitoring is being added to surface these issues faster if they occur.

We are currently investigating reports of notifications tied to Review Notes not being received

The fix for this issue has been released. Users may experience a brief delay as the backlog of queued notifications is processed. We are continuing to monitor the situation and will share a Root Cause Analysis here when available.

We are currently investigating an issue where various functions within the FloQast application are erroring out, showing either a Lambda error or a Runtime error. This is being treated with the highest priority

The issue has been identified and a fix is being implemented.

The fix is currently being applied in parallel to all FloQast environments. We expect the full resolution to be in place very soon.

The fix has been initiated, and we are monitoring the results. We are aware of some errors still occurring due to warm lambdas which have not fully finished restarting yet. If a service is used and a lambda that has not been fully restarted yet is invoked, an in-app error may still occur.

The fix for this incident has finished deploying. A full RCA will be shared in this posting as soon as it is available.

**Summary:** On May 7, 2026, from approximately 07:15 AM to 05:21 PM PT, customers across all regions experienced failures in automated workflows and email notifications within FloQast, resulting in jobs failing to execute as expected. **Root Cause:** A routine update from our cloud infrastructure provider changed how certain internal network traffic was handled. A prior update within our platform had not been fully applied across all parts of our environment, which created a conflict with the provider's change. Affected workflows failed immediately rather than completing normally. **Immediate Resolution:** The infrastructure update was rolled back to a prior stable configuration, and a process was run to fully refresh the affected workflows across all regions. All three regions were subsequently returned to normal operation. **Follow-up Actions:** We are taking several steps to strengthen our resilience to infrastructure changes of this kind. Going forward, updates from our cloud provider will be validated in a dedicated test environment before reaching production, giving us earlier visibility into any compatibility issues. We are also enhancing our internal monitoring to provide greater coverage across our infrastructure, and we are improving how we receive and act on cloud provider advisories so our engineering team can respond proactively to changes that may affect our environment.

We are currently investigating reports of errors navigating the Single Workflow Dashboard. Users may see an error message when navigating between the Overview, Timeline, and Entities sections. After closing out of the error, the page should load as expected. The All Workflows Dashboard is not affected. We will post an update here as soon as we have more information.

We have identified the cause of the issue and are working on a fix. Users may still see the error when navigating between the Overview, Timeline, and Entities sections of the Single Workflow Dashboard. Closing the error will allow the page to load.

The fix for this issue has been released, and users should no longer be receiving errors when navigating the Single Workflow Dashboard. We are continuing to monitor performance, and a Root Cause Analysis will be shared here when it is available.

**Summary:** On May 5, 2026, customers navigating between tabs on the Single Workflow Dashboard encountered an error modal displaying "Something Went Wrong." While the underlying dashboard data continued to load normally in the background, the error modal obscured the experience for customers using that view. **Root Cause:** A recent update to the dashboard introduced a timing conflict in how the system managed temporary data storage during tab navigation. When customers switched between tabs, the system was clearing an internal data cache before a background process had finished using it, which triggered an error. The issue was most pronounced for customers on slower network connections, where the timing gap was more likely to occur. **Immediate Resolution:** The update that introduced the timing conflict was reverted, restoring the proper sequence of operations. **Follow-up Actions:** Test coverage is being expanded to test rapid navigation scenarios on the Single Workflow Dashboard to catch this class of issue before it reaches production. The underlying dashboard improvement that was reverted will be re-implemented with a safer approach before being reintroduced.

We are investigating an issue where changes made through the All Entities Reconciliation Template are appearing in Admin Settings but not syncing to the Reconciliations tab. Please note that the Checklist is unaffected. As a temporary workaround, navigating to the Individual Reconciliation Settings page for a specific entity and clicking Save will apply any updates to that entity.

We have identified the cause of the issue and are working on a fix.

We have successfully deployed a fix and confirmed that changes made through the All Entities Reconciliation Template are now syncing correctly to the Reconciliations tab. A formal Root Cause Analysis (RCA) will be shared here once it is available. If there are any recent changes made via the All Entities Reconciliation Template that you do not see applied, re-applying the template should resolve the issue.

**Summary:** Customers using Reconciliations experienced an issue where changes made via the All Entities template were saved in settings but failed to apply to individual periods. This resulted in template updates not being reflected across the application and a lack of email notifications for these bulk updates. **Root Cause:** A standard infrastructure upgrade changed how internal system information was passed between background services. This caused a critical communication failure that prevented the automated workflow from distributing template changes to the appropriate records, which occurred without surfacing an error message to the user. **Immediate Resolution:** Engineering teams implemented a multi-layered fix that restored the necessary system context and updated the underlying software dependencies. After rigorous testing across multiple environments to ensure full functionality and the restoration of automated notifications, the fix was deployed to all customers. **Follow-up Actions:** To prevent a recurrence, the team is enhancing end-to-end regression testing for infrastructure changes and improving monitoring to ensure visibility into background service health. Additionally, system alerts are being updated to provide immediate notification of failures in automated workflows, and internal deployment checklists are being refined to ensure consistent dependency management during platform upgrades. **Recommended Customer Action: Any customers who made Reconciliation updates via the All Entities Reconciliation Template between 2:26 PM PT on April 20 and 3:16 PM PT on April 23 should re-apply their reconciliation templates to ensure the changes are properly applied.**

We are currently investigating this issue.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

**Summary:** Clients experienced failures when attempting to push files through FloQast's SFTP integration. Automated file processing was interrupted across all production regions. **Root Cause:** A recent update to FloQast's file processing pipeline introduced a dependency on a new configuration that had been validated in a test environment but had not yet been applied to production. When the updated code was deployed to production, the underlying configuration it required was not in place, causing the file routing service to fail on startup. **Immediate Resolution:** Engineering teams identified the missing configuration and applied it across all production regions. **Follow-up Actions:** The team is implementing cross-repository deployment safeguards to ensure that when code changes and their corresponding infrastructure configurations are developed together, both are verified as deployed to production before either is considered complete. This will prevent scenarios where tightly coupled changes across different parts of the system can become inadvertently separated during the release process.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

**Summary:** Clients experienced “Something Went Wrong” errors throughout certain parts of the application. **Root Cause:** As part of ongoing security infrastructure improvements, FloQast migrated services to a more robust web application firewall \(WAF\) configuration. In pre-production environments, a supplemental ruleset had been in place that, by design, took precedence over certain standard security rules — effectively masking how those rules would behave in production. When the migration to the stricter production security configuration occurred, legitimate integration traffic was inadvertently caught and blocked. **Immediate Resolution:** Engineering teams performed a full rollback of the affected deployments, restoring integration functionality for impacted customers. Once stable, the team began a careful analysis of the specific security rules to confirm that the appropriate level of restrictions was being adhered to. **Follow-up Actions:** The team is taking a deliberate approach to reintroducing the production security ruleset in monitoring mode before enforcing blocks, allowing for validation against known traffic patterns.

We are receiving reports of 403s when interacting with specific API endpoints such as our Trial Balance or Chart of Accounts endpoints

A fix has been implemented and we are monitoring the results.

The fix for this has been deployed, and the incident has been resolved.

**Summary:** Clients experienced authorization errors \(403s\) when attempting to push data through FloQast's external API integration pipeline. **Root Cause:** As part of ongoing security infrastructure improvements, FloQast migrated services to a more robust web application firewall \(WAF\) configuration. In pre-production environments, a supplemental ruleset had been in place that, by design, took precedence over certain standard security rules — effectively masking how those rules would behave in production. When the migration to the stricter production security configuration occurred, legitimate integration traffic was inadvertently caught and blocked. **Immediate Resolution:** Engineering teams performed a full rollback of the affected deployments, restoring integration functionality for impacted customers. Once stable, the team began a careful analysis of the specific security rules to confirm that the appropriate level of restrictions was being adhered to. **Follow-up Actions:** The team is taking a deliberate approach to reintroducing the production security ruleset in monitoring mode before enforcing blocks, allowing for validation against known traffic patterns.

We are currently aware of an issue resulting in specific admin settings pages not loading.

The issue has been identified and a fix is being implemented.

The fix has been deployed to all regions, and functionality is now restored. We will continue monitoring for any unexpected behavior.

**Summary:** Clients experienced failures when attempting to load most Admin pages within the application. The Team page remained accessible, but all other Admin pages were unavailable during the incident window, which lasted approximately 27 minutes. **Root Cause:** During a scheduled release, certain application components were deployed out of the intended order. Specifically, updated client code was deployed before the underlying services it depended on were in place, causing Admin pages to fail to load when users attempted to access them. **Immediate Resolution:** Engineering teams identified the deployment sequencing gap and completed the deployment of the missing components. Once the remaining services were deployed in the correct order, Admin page functionality was fully restored across all affected users. **Follow-up Actions:** To prevent similar occurrences, the team is implementing clearer documentation of deployment ordering requirements for complex releases, ensuring all dependencies are explicitly captured and confirmed with relevant stakeholders before deployments begin. Internal release coordination processes are also being reviewed to reduce the risk of sequencing gaps, particularly in releases involving multiple simultaneous updates.

Summary: Recent deployment of a core service caused a cascading 500 error when users attempted to access TB (Trial Balance) upload folders. The error originated from a failed HTTP request with status code 500.

Resolution: Reverting the recent deployment fixed the issue.

We are currently looking into an issue where a 500 error displays when using the AI creation method to generate a rule within the Matching product.

This issue has been resolved after a newly introduced configuration requirement was made between FloQast and OpenAI. New regional configurations are now in place, and our team has validated that matching rules can be created in all three FloQast regional databases again (US, EU, AU).

We have identified an issue where Checklist items are erroneously assigned a new Template ID when imported via the Single-Entity or All-Entities template. When an impacted template is applied via the Admin Settings > Checklist page, the updated Template ID causes a brand-new version of the checklist item to be created in the relevant periods. For items that have been fully signed off in those periods, absolutely no sign-off data is lost on the original item, but it will appear that the item has "duplicated" since this net-new version has also been added.

The issue has been identified and a fix is being implemented.

A fix for this issue has been implemented, preventing additional erroneous duplicate tasks from being created. Work is ongoing to correct the tasks that have already been created.

This incident has been resolved.

We are currently investigating an issue for our EMEA and APAC customers where an error message displays when clicking on a review note.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

We have received reports of intermittent 500 errors, specifically in the Journal Entry Management module. We have identified the issue and are actively working on releasing the fix.

A fix has been implemented, and the issue is confirmed resolved.

We are investigating reports of issues loading the Transform AI Agents page. We will provide an update as soon as more information is available.

The issue has been identified, and a fix is being implemented.

This issue has been resolved, and the Transform AI Agents page is now fully operational. A Root Cause Analysis will be posted here when available.

**Summary:** Clients experienced failures when attempting to load the Transform module, receiving an error indicating that their user identity or team membership could not be validated. The issue affected all users attempting to access Transform during the incident window. **Root Cause:** A code update introduced a dependency on a new policy definition that had not yet been deployed to the supporting authentication service. When users attempted to load Transform, the system was unable to complete the required identity and access validation, resulting in a load failure. **Immediate Resolution:** Engineering teams quickly identified that the issue stemmed from a mismatch between the recently deployed code and the underlying authentication service. The update was reverted to the previous stable release, which did not rely on the unavailable policy. This restored normal Transform functionality for all users within approximately 22 minutes of the issue being detected. **Follow-up Actions:** To prevent similar occurrences, the team is reinforcing the practice of ensuring all service dependencies are deployed and verified before releasing dependent code changes. Additionally, efforts are underway to improve how the application handles upstream service unavailability, with the goal of providing clearer, more actionable messaging to users rather than a hard failure, and to better equip support teams for faster diagnosis.