Legend

Reducing financial reconciliation errors.

Legend is an affiliate marketing company operating in the gaming and sports industries. As a product designer, I led a suite of internal products spanning analytics, CRM, and financial logging. This project focused on keeping monthly partner earnings accurate, current, and auditable.

Legend internal analytics tool

Problem

Legend’s monthly earnings depended on data from many affiliate partners. Some partners provided data through APIs, while others had to be scraped because their systems did not expose a reliable integration. Partner values could be incomplete, delayed, incorrect, or corrected after submission.

Commercial specialists owned the relationship with partners and were responsible for keeping these earnings accurate. Before this work, many corrections arrived by email, were added manually to spreadsheets, and then had to be communicated to finance so bookkeeping records could also be corrected.

The product problem was to preserve that flexibility while making the data trustworthy for finance. If values changed after month-end bookkeeping, the business needed to know what changed, why it changed, and whether the change required a retrospective correction.

My role

My role was to diagnose the causes, prioritise the workflows that carried the most operational and legal risk, design the solution, and work with engineers to ship it gradually into the finance and commercial teams’ existing processes.

Reliability indicator detail

Discovery

I observed commercial and finance teams, interviewed the people responsible for partner data, and inspected the spreadsheets they used to handle corrections. That helped me separate the upstream data problems we could not control from the product workflow gaps we could fix.

Decision-making

The key decision was not to pretend the partner data could be perfectly automated. Bad upstream systems were outside our control, and corrections were a legitimate part of the business. Instead, I focused the product on making uncertainty visible before it became a finance problem, and making post-close changes explicit when they did happen.

That meant preserving commercial specialists’ ability to correct earnings, while adding stronger controls around month-end close: reliability signals, locked periods, mandatory reasons, and history that finance could trust.

Constraints

The operating environment made full automation unrealistic:

Affiliate partners did not always offer APIs, so some data had to be captured through unreliable scraping. Partner systems could also expose delayed or corrected values after the original submission.

Commercial specialists had no clear signal for which earnings needed attention first. Corrections were not classified by cause, whether partner update, scrape failure, or human error, and month-end closures did not have a reliable history for audit purposes.

Month-end locking detail

Solution

  • Reliability indicators

    I introduced a data quality indicator that surfaced earnings needing attention across scrape failures, delayed partner data, missing values, late changes, unreliable partners, and high-value accounts. This gave commercial specialists a prioritisation layer for fixing the data finance would later depend on.

  • Month-end locking and exporting

    I introduced a process for approving financial values before month-end closing, then locking them so post-close changes were clearly distinguished from ordinary edits. This helped the product reflect the bookkeeping state finance was working from.

  • Logging edits and history

    I introduced a mandatory reason before changing data, plus a history view that exposed edits and month-end closures. This made corrections easier to explain, review, and audit.

Impact

Before
Corrections travelled by email, into a spreadsheet, then to finance, who corrected the bookkeeping the following month. Nothing flagged which earnings were at risk, and month-end had no audit trail.
After
Reliability indicators surface the at-risk earnings first. Values are approved and locked at close. Every change carries a mandatory reason, and a history view retrieves exactly what changed and why.

The changes were released gradually and validated with commercial specialists, finance, and audit scenarios. They replaced the Excel-based reconciliation process and cut retrospective corrections, the count of partners still needing a fix after month-end closing, by 44% month over month.

Finance also gained a detailed, retrievable history of every month-end close. Instead of reconstructing what happened from a trail of emails and spreadsheet edits, they had a reliable record of what changed, when, and why.

Edit history detail