Financial reconciliation

Problem

Every month, finance teams at companies using Adyen as a PSP need to perform financial reconciliation, pulling data from Adyen’s customer portal. Getting it meant downloading multiple reports, combining the data, and transforming it—a tedious, time-consuming process riddled with problems like incomplete or incorrect data. They needed an easier way.

Opportunity

Rather than make accountants dig through 70+ Adyen reports to find what they needed, we could surface the precise numbers directly, exponentially reducing the time it takes to reconcile.

Research & scoping

Since no one on the team had experience with financial reconciliation, the first order of business was to speak with Adyen’s customers—specifically their accountants and controllers.

I wrote the interview guide and led more than a dozen interviews with merchants to understand how they reconcile and where the major pain points were.

The interviews revealed 3 common themes:

• Timing and data accuracy were critical, and Adyen’s reports—generated on Amsterdam time—caused major problems for merchants outside central Europe
• Merchants only needed detailed breakdowns when something looked amiss—and then they needed everything we could give them
• Adyen’s reports and terminology were too opaque and Adyen-specific to reconcile easily with merchants’ own data

We decided to zero in on one piece of the process: accounts receivable—how merchants answer the question, “How much of my money has Adyen not paid out to me yet?” The PM and I collaborated closely on scoping the functionality that would deliver the most value.

The holistic picture

As I worked on the accounts receivable experience, I continued to advocate for a more holistic approach, as the previous merchant interviews had indicated that accounts receivable, accounts payable, and cash aren’t reconciled in isolation.

So I began a parallel project with another PM to verify that a holistic approach would bring more value, and to rigorously map the full picture so we weren’t designing with blinders on.

We ran further merchant interviews with a scrappy prototype, which confirmed my hypothesis. From there, I mapped every reconciliation job-to-be-done into a blueprint for a scalable experience.

Technical constraints

The northstar version of the accounts receivable experience that I shared with the wider team raised concerns with the data engineers. To fix the timezone data issue, I’d proposed a flexible, real-time dashboard merchants could configure to their business setup. However, the existing data architecture couldn’t support that without a multi-year restructuring.

No problem—time to generate alternatives. Instead of a real-time dashboard, I designed a one-time setup flow: merchants would tell us when they needed the data, and we’d make sure it was ready on time and covered the correct period for their time zone.

This was much more feasible, and testing it with merchants raised no red flags.

Pilot & general availability

Because this project was no small undertaking, I worked with the PM to define three successive milestones, so we could deliver the core value to merchants quickly while we iterated.

We launched the first milestone to a select group of pilot merchants, and it was enlightening to see it in use with real data, fitting into their existing reconciliation processes.

Pilot feedback confirmed the new experience solved the timeliness and accuracy problems, and also helped me refine the subsequent milestones, which were launched to general availability in early 2026.

In the first two months of general availability, the average time to reconcile accounts receivable dropped from 6 hours to just 15 minutes.