A year ago, we rebranded our website. It felt like the right moment to ask a harder question: did the product itself still reflect who we are and what we’ve built? The honest answer was no. So today, I want to talk about why we’re rolling out a new user interface for Actuals, what changed under the hood, and why we think this is just the beginning.

The problem we didn’t talk about enough

Actuals started as a reconciliation tool, and for many customers, that’s still the first thing they think of when they hear our name. But over several years, our platform quietly grew into something much bigger: a financial data foundation, financial-native reporting, AR and AP insights, subledger visibility, audit trails per transaction. The trouble was, a lot of that depth was hard to find. Our old interface simply wasn’t built to show the full picture, and if customers can’t see what a platform does, it may as well not do it.

The new UI’s sidebar and navigation now follow the actual rhythm of a month-end close: import, transformation, reconciliation, reporting, export. It sounds like a small change, but it means the platform’s structure finally matches the way financial professionals actually work. These steps are the typical steps we have seen our users take as part of their month end close and align the top level menu items with these steps means that users can navigate quickly from the a small list of items. We also renamed things where the old language didn’t fit. “Unmatched transactions,” for instance, is now “exceptions,” which is both more accurate and more familiar to anyone who’s run a close. Additionally we renamed Ledgers to General Ledger Accounts and the current Overview page is available as Reconciliation Overview. The documentation of the web app has been updated to have an overview of old and new names so users can find their way quickly

It’s also about what happens when you open the app

The first thing you’ll see now is an overview page combining several bits of information: which periods are open, which are closed, and a combined view of monitoring events that used to live in disconnected corners of the product. From there, you can click straight into the dashboards and reports you actually need. It’s a small thing to describe and, we hope, an obvious thing to feel. A key thing we wanted to include is not just which reports are available but also if you can use them at all. If something is wrong, you can work on the fix first instead of working with incorrect or incomplete data in your reports

Update for performance

Some of you told us the old UI didn’t feel snappy, especially once your data volumes grew. That feedback was fair, and we spent real engineering time on it. We improved the communication with the backend and added additional caching throughout. Just as importantly, we changed how we request data where needed. Overall we are quite happy with the results from a performance perspective, the transaction details page has seen a 40% better performance when testing for large volumes.

How we built it

We built a modern tech stack React Router Framework with Typescript from the ground up. This allowed a closer coupling between backend and frontend resulting in faster and more efficient development and maintenance. We used AI-assisted tooling, specifically Cursor, to accelerate generating new pages and iterating on them. The specific setup is worthy of a separate post, the key thing It let a small team rebuild the experience in about two to three months. We were able to complete the work according to plan primarily because we did not only use AI to generate code, but also to review, test and document. We have had the feeling of many junior colleagues being available to us in the last few months allow us to focus on the high impact decisions and validations.

One clarification I think is worth making explicitly: we used that tooling for development only, not for hosting. Our platform continues to be hosted under our own infrastructure and governance, in line with our SOC 2 Type 2 certification. Speed was the goal but compliance was never up for negotiation.

What this release is, and isn’t

I want to be transparent about something: this isn’t a release packed with flashy new features. It’s a foundation. The design system, the faster build workflow, and the underlying architecture all make future development easier and quicker, and we intend to use that. AI-driven capabilities are next on our roadmap, and this UI is what makes building them practical rather than painful.

What changes for you, practically

Your data is exactly the same. Nothing about your underlying records changes. Starting this month, every customer can access the new UI through a link inside the current app, and it’s entirely your choice when to switch. We’ve built an in-app tour to guide you through where things live now, and we’re publishing a dedicated guide mapping old locations to new ones. We’re currently aiming for December 1st to retire the old UI, but that date isn’t fixed in stone. If you need more time, or if everyone’s ready sooner, we’ll adjust.

Five years is a long time in software. We built something we’re proud of, we listened to what wasn’t working, and we tried to be upfront about both. That combination, more than any single feature, is what we hope you notice. As Actuals is the foundation to your financial operation, the new UI is the foundation to building the next capabilities on our platform. In the coming months you can expect updates on Native reports, Reconciliation options and native exports.