Global Pay Reports

The problem

The impetus for Global Pay Reports was the EU Pay Transparency Directive but we quickly learned the scope of pay reporting had a bigger addressable market. The UK has gender pay-gap reporting. Australia has WGEA. Every multinational employer has a growing list of country-by-country compliance burdens that don't talk to each other.

For Syndio's customers, global HR, compensation, and legal teams, non-compliance meant fines, audits, and contract clawbacks. The status quo was a tangle of spreadsheets, jurisdiction-specific consultants, and bespoke processes. The opportunity was to ship a single product that turned all of that into one workflow.

Scope

• Cover 35 jurisdictions across 43 countries at launch
• Generate accurate, jurisdiction-specific filings without forcing the customer to be a regulatory expert in every country
• Be auditable. Every filing had to show its work
• Be accessible at WCAG 2.1 AA from day one (international contracts required attestation)

I joined customer calls with HR directors and compensation analysts at multinational employers. Companies running pilot pay-gap reports under interim regulatory guidance in the EU, and companies already filing in jurisdictions where reporting laws had been on the books for years (UK, Australia). Three findings reshaped our PRD:

1. Cross-jurisdiction comparison was the killer feature. A multinational HR team didn't want 35 disconnected filing tools. They wanted one place to see every jurisdiction's status side-by-side, knowing the methodologies differed.
2. The audit trail mattered as much as the report itself. Compliance officers wanted to show how a number was computed, not just submit the number. Every filing needed to be reproducible.
3. Crawl, walk, run. The compliance space in 2025 for pay reporting was quick moving. We had to be first to market.

In accordance with our crawl, walk, run philosophy, we sectioned the work off into two buckets: guided and team-assisted reports.

Team Assisted reports

All 35 reports started as team-assisted reports. A customer fills an offline template provided by Syndio, hands it back, and the Syndio team produces the report by hand. The product surface for these is just a card pointing the customer at the template.

As we saw which reports were getting the most usage, we prioritized that jurisdiction for automation into a guided report. In a guided report, a customer uploads their data, the product generates the regulatory report end-to-end, customer downloads it. No Syndio team involved in the day-to-day filing.

Each jurisdiction then opens into its own report wizard. The three-step rhythm — download a template, upload the completed data, download the generated report — stays the same across every country, but the regulatory context above it (snapshot dates, scope, where filings get submitted) is country-specific.

Guided reports

A guided report is the end-to-end self-serve version of a pay-reporting filing. The customer never talks to a Syndio person to get it done.

The customer uploads employee data into a jurisdiction-specific template, the product validates the upload, runs the regulatory calculations, and emits the filing in the format the regulator expects.

Regulatory overviews were important to the views of each guided report. They provide the user with pertinent information about their report. Every number in the generated report is reproducible from the uploaded data, so a compliance officer can answer why a figure looks the way it does, not just what it is. The "show your work" principle was non-negotiable: a fast report a customer couldn't defend in an audit would have been worse than the slow one they already had.

This was a from-scratch product. I owned the frontend end-to-end. The repo, the build pipeline, the design-system integration, the accessibility framework, every component that shipped.

Building the repo for accessibility from day one

I set up the codebase so WCAG 2.1 AA compliance was structural, not retrofitted:

• Primitives Buttons, inputs, links, menus, dialogs. Built with full keyboard support, focus management, and semantic HTML from the first commit. Design tokens drove contrast ratios; nothing could ship under 4.5:1 for normal text or 3:1 for large text.
• Composed components Data tables, the filing wizard, the comparison dashboard. Wrapped primitives so the accessibility properties propagated automatically. aria-live regions handled async submission feedback. Long-running flows announced progress to screen readers.
• Skip links, landmarks, and a logical tab order were baked into the page-level layouts. Every route was navigable end-to-end with the keyboard alone.

CI/CD quality gate

I integrated Playwright + axe-core into CI as a quality gate. Every PR ran a full a11y regression sweep before merge; failing accessibility violations blocked the PR alongside failing tests. Two months in, accessibility was a green-check thing, not a "we'll fix it later" thing.

Beyond the metrics, the deeper outcome was procedural: this was the first Syndio product to ship with accessibility as a structural property of the codebase rather than an audit at the end. The framework outlived the launch, every product since has piggybacked on it.

• Accessibility as load-bearing infrastructure. Building WCAG into the primitives and putting axe in CI from the first commit was the highest-leverage decision of the project. Every later feature inherited compliance for free; retrofitting would have cost an order of magnitude more time.
• Show your work as a design principle. Compliance products live or die on their audit trail. Customers don't trust numbers they can't reconstruct. Every state-changing interaction in the product can answer why alongside what.
• Make jurisdiction differences explicit. Hiding methodological differences in the name of a clean UI is a compliance lie. The dashboard tells customers that Germany ≠ Spain, on purpose.