75% workflow reduction with Archie's first accounting integration

Archie is a B2B SaaS platform that centralizes vendor and invoice management, making it easier for businesses to track, manage, and process payments. With features like real-time invoice tracking, in-app communication, and a detailed activity log, Archie reduces manual work and eliminates the need for scattered tools. Our clients use Archie to streamline financial operations, improve team collaboration, and ensure vendors get paid on time.

When we set out to build accounting system integrations, the vision was simple—make it effortless for customers to sync their invoices without extra manual work. No more exporting spreadsheets, no more cross-checking numbers in multiple systems. Just a smooth, reliable connection that fit seamlessly into their existing workflows. If we got this right, customers wouldn’t just see Archie as an invoicing tool; they’d trust it as a core part of their financial operations. And for the business, this meant stronger retention and higher adoption among larger clients—because seamless accounting integration would remove a major blocker to scaling with us.

But we weren’t there yet. We were losing deals with bigger customers because we didn’t integrate with any accounting systems. Instead, users had to manually export invoices, manipulate data in Excel, and re-upload everything into QuickBooks—every single week. It was slow, error-prone, and frustrating. A recent churn event made it clear this wasn’t just a nice-to-have. A high-value customer left Archie because we didn’t support QuickBooks, proving this was mission-critical. To fix it, we needed to build an integration that felt seamless, trustworthy, and low-maintenance for our users.

We had strong signals that this was both necessary and doable. I personally interviewed every Archie customer using QuickBooks and found that they were spending hours each week on repetitive manual work. They didn’t need real-time syncing—just a daily sync with an option to trigger it manually. And invoice mappings weren’t one-size-fits-all; customers had different ways of categorizing vendors and transactions, so flexibility was key. Competitor benchmarking confirmed the opportunity—other platforms had QuickBooks integrations, but users found them rigid and frustrating. We had a chance to build something better.

We took a phased approach to build momentum. First, we implemented the Railz API to connect to accounting platforms. Then, we focused on launching with QuickBooks as our highest priority, gathering feedback, refining the experience, and setting the stage to expand to additional platforms. But the project lacked urgency at first. The PRD was still in draft, and engineers were still learning the limitations of Railz. I took the lead—initiating discussions, sharing early sketches, and prototyping workflows to get buy-in and build momentum.

One of the biggest, unexpected challenges was handling missing mappings. For invoices to successfully appear in QuickBooks, 3 objects in Archie must have completed mappings: the payment method, the vendor, and the line item on an invoice. When discussing the requirements, we agreed as a team to design a basic modal that flags if mappings are missing. During the design, I noticed this would be a huge point of frustration for the user, and could potentially cause them to disconnect the integration (worst possible scenario). To combat this, I designed a modal that flagged the specific mappings that are missing and enable the user to fix them in real time. That way, they wouldn't have to backtrack to guess what is missing.

This was a clear UX improvement, but wasn’t an easy sell. The Head of Product hesitated due to time constraints, and the Engineering Lead was concerned about scope. To better support my stance, I created prototypes showcasing the original plan versus the suggested flow. After seeing the difference, the engineer became a champion for the change, and the Head of Product was hesitant, but agreed to move forward.

This was the first iteration I designed, including every possible piece of information we might want on the modal. When designing, I considered both workflows: paying a single invoice (left) and paying multiple invoices (right). I worked with the lead engineer to figure out a solution in mapping the invoice items, since there could be several in the future, and landed with the following approach. I knew we were spending too much time on this, so pushed for us to design for the current state, which would be 1 invoice field per line item, and tackle the multiple fields when we actually planned on implementing that.

This was the simplified version that I came up with. Since there was only 1 field per line item, I checked the data to find out the average number of line items, which was 3, so proposed offering the ability to map the line item directly from the invoice. This invoice could get long if there was >3 line items, especially if the user is bulk paying invoices, but it was a risk we were willing to take given our tight timeframe.

When successfully launched the first iteration of the QuickBooks integration in 2 months, meeting our deadline. Customers immediately saw the value. User feedback validated that the automatic sync and mapping process was far better than their existing manual workflows.

I designed a new “Integrations” page in Settings that allowed users to connect the integration and easily adjust details, while Archie handled the time consuming workflows by syncing the data on a daily basis. The integration was designed to simplify workflows, save users time, and reduce the risk of errors.

I allowed the user to specify mappings anytime they were adding or editing a vendor. I designed this flexibility to accommodate different user workflows and permissions, allowing for a smoother integration into their daily tasks. Mapping was kept optional, recognizing that the individual performing the action may not always have the necessary mapping information. All fields were connected, so updating in one place would be reflected in the other.

If users specified that they didn't want the default vendor value to be applied to all legacy vendors, then I knew I needed to design a way for the user to find legacy vendors that had not been mapped to QuickBooks. I wanted to design a vendor management center, where the user could quickly apply mappings without a thousand clicks, but that solution was not feasible for this first iteration. As a workaround, I added a filter on the Vendors page, allowing the user to separate mapped from unmapped vendors, then take the necessary action.

I added the ability to map bank accounts when adding and editing a bank account, as well as managing the integration details. I took a look at our customer data, and the max amount of bank accounts added was 2. The probability of customers adding more than 5 was unlikely, so I allowed the user to map those bank accounts when setting up the integration for efficiency. All fields were connected, so updating in one place would be reflected in the other.

I added the ability for the user to map each line item (a necessary field for invoices to appear in QuickBooks) from the edit invoice view. There was more to be done here to improve the user experience. However, due to timing, we had to bump improvements to the next iteration, especially with the addition of other QuickBooks invoice line item fields like "Class" and "Project".

In a dream world, I wanted the user to be able to add automatic mappings by changing the form type of the "Item" field from an input to a fixed dropdown list. In the past, customers expressed that they wanted more control over what the vendor can input there, so it's a win-win. Imagine a field creation / mapping area in Settings where the user can select if they want the vendor to input items freely or choose from a list, define that list, and specify the QuickBooks mappings for those fields that would be automatically applied when the invoice is submitted. Magic! But magic for another time.

When viewing an invoice, I wanted users to be able to quickly reference mappings for status and accuracy. To achieve this, I added the mapping details directly on the invoice preview. To view, the user can expand the total amount widget to see the individual line items in addition to the corresponding mappings.

This wasn’t just an integration—it was a foundational shift in how Archie fit into our customers’ financial ecosystems. Now that the groundwork was in place, we can scale integrations to more accounting platforms, further solidifying our market position.

The biggest lesson? Momentum matters. When teams aren’t moving, sometimes it takes someone to push things forward. Also, when advocating for UX, showing is always more powerful than telling. By proving value through sketches and prototypes, I was able to influence product decisions and ensure we built something that truly made a difference for our customers.