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.
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.
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.
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
The solutions were released gradually and validated with commercial specialists, finance, audit scenarios, and the retrospective correction metric. Within the first month of most changes being released, error rates dropped by 44%, measured by instances of partners that needed retrospective correction after month-end closing.
We also gained the ability to retrieve a detailed history of month-end closures for auditing purposes, giving finance a more reliable record of what changed and why.