Automating the first sales tax collection at Later
Simplifying global tax compliance for creators and small businesses, while unlocking revenue potential.
In 2023, we launched sales tax collection to comply with the Wayfair ruling in the US, which requires businesses to collect sales tax on US sales based on transaction thresholds set by each state.
Challenge
Later hadn’t been collecting sales tax from US customers.
Now the opportunity presents itself to start sales tax collection in the states, and expand the project to Canada, Europe and the UK – all of which are key markets of the company.
I led in various capacities: research support, product strategy, and end-to-end design. Collaborating with leaders at Later to influence the strategic vision and product roadmap, the goal was to simplify the sales tax process for our customers for their small businesses.
role
Product designer
year
2023
disciplines
Interaction & experience design
Product strategy
Research
Human interface design
What
impact
did we make?
cost savings
$1M+
sales tax collected within 6 months
adoption
70%+
VAT input adoption
usability
<1%
average error occurrence rate in address entry
risk reduction
95%+
tax calculation accuracy
Preview only. See the rest of what we launched below ☺
How it started: Discovery
How it started: Discovery
Why
Why
reimagine sales tax
reimagine sales tax
?
?
Everything changed for SaaS businesses when the Wayfair ruling landed…
Everything changed for SaaS businesses when the Wayfair ruling landed…
…and Later's legacy payment process wasn't fit for the new sales tax collection requirement.
…and Later's legacy payment process wasn't fit for the new sales tax collection requirement.
The existing payment system currently lacks the top half of the hierarchy crucial for sales tax compliance, and will lead to increased operational costs.
Initially, SaaS companies based in Canada like Later were only required to collect sales tax in states where they had a physical presence. Nothing else needed to be accounted for, including whether or not customers needed to pay tax.
If Later keeps paying taxes out-of-pocket for each taxable customer, it would cost the business millions.
Why were we
blocked
from collecting tax?
from tax collection?
Entering tax info
in-app was only good for documentation.
(
A high impact, high effort fix)
What happened?
In 2021, the previous team added a basic form in Later’s Settings page to let users display their business name and tax number on invoices.
This was a quick solution implemented in response to recurring customer support requests.
The issue
Users still struggled with the overall tax filing process.
Despite meeting demand, it was a band-aid solution that only solved a surface-level need.
New opportunity
With the in-app sales tax collection launch, the collected tax information could be used to further support users in the tax reporting process.
Over 50%
of new users (outside the US & Canada) were left confused after entering their addresses.
(
A high impact, low effort fix)
Why were we
from tax collection
blocked
?
What happened?
The existing checkout address form, originally designed for US and Canadian formats, don't follow conventions for many international users living elsewhere.
Correct entries flagged
The form's inline validation often flagged correct entries as errors or suggested inaccurate alternatives, based on US/Canada regex.
Result: failed payments for international customers
Suggestions were based on US/Canada regex, and behavioural analysis showed many international customers accepted incorrect suggestions out of frustration just to move forward, which led to many failed payments.
Implication: collected addresses are inaccurate
We had a widespread of data inaccuracies in the system that can't be used for charging sales tax. Identifying this friction point helped me prioritize redesigning the address input to better support global formats, reduce user confusion, and use correct data for compliance.
What did
stakeholders say
?
What did
stakeholders say
?
"Priscilla, global tax rules are tricky."
"Priscilla, global tax rules are tricky."
…revealed the PwC consultant
Speaking with subject matter experts revealed that different countries treat tax differently.
Collaboration with tax experts
Objective:
Dig into the underlying concerns to ensure most experience touchpoints are met.
I met with tax consultants to understand compliance with various B2B tax regulations.
Key learnings
1.
US: sales tax varies by location, and there is no reverse charge mechanism
2.
Canada: GST is federal, while HST/QST adds provincial tax layers
3.
EU: VAT is charged based on the customer's country, not seller's. Requires two pieces of evidence to verify location (e.g. IP and billing)
4.
UK: Post-Brexit, UK has its own VAT system and no longer part of EU VAT OSS
5.
Mental model mismatch exists: what we understand about taxes vs. how users perceive them
So where's the
mental model mismatch
?
Where's the
mental model mismatch
?
We're allowing customers to add tax info to invoices for proof of purchase, but the tax refund process is slow. Meanwhile, users who haven't entered in their information were quite confused, as they expected entering their address would perform a reverse charge on their bill.
Sales tax in the real world
A core finding that stood out from collected data and market evaluation was that Later's existing payment experience didn't align with the real-world mental model of collecting sales tax, especially in new jurisdictions.
In reality, with accurate address and eligible tax information on-hand, we could support customers with reverse charging the tax amount, simplifying their overall accounting process for their own businesses down the road.
Different address formatting
The discovery on the usability issue led to seeing how different regions format addresses.
The UK alone was tricky: flat numbers came before house numbers, counties are optional, and postcodes didn't always map clearly to tax zones.
Then came the EU: Germany's strict street spellings, France's multi-line quirks, and the Netherlands' hidden suffixes. It felt like we needed to cater twelve different checkouts in one, and we knew that wasn't feasible with the time constraint.
Then came the EU: Germany's strict street spellings, France's multi-line quirks, and the Netherlands' hidden suffixes. It felt like we needed to cater twelve different checkouts in one, and we knew that wasn't feasible with the time constraint.
Breaking down the business initiatives into user needs and JTBD
The Process
Overview
The Process
Process: Reimagining tax
What did
stakeholders say
?
1.
I formed a hypothesis.
By redesigning address validation logic, we can…
Automatically charge tax when applicable
Increase checkout conversion
Be legally compliant with the new guidelines
2.
Developed the Sales Tax Loop for product and dev alignment
The key was finding the sweet spot between revenue goals and user experience to get buy-in. I created a simple sales tax loop framework to provide product and dev teams a shared language.
The Sales Tax Loop
By: Priscilla
In short, the loop shows that opening Later's rigid address flow would better support accurate sales tax collection, balancing both business and user needs.
3.
I pushed for an A/B test when Product wasn't initially convinced.
Product prioritized revenue and didn't believe that many users will bypass the existing address form with incorrect addresses. Along with developers, I was concerned about compliance risks and long-term costly fixes.
I proposed a quick A/B test on the production environment to gather more data before our team jumped into a full sales tax rollout.
4.
We visualized success.
The team aligned on a few benchmark business KPIs, including:
Checkout completion time decreases by 4-6%
Cart abandonment rate decreases by 5-8%
VAT input adoptions by new and existing customers increases by 40%
$250k sales tax collected within the first 6 months
Design success looks a little different, though. There were opportunities to reduce time and complexity for an overall better usability: a shorter, smoother checkout flow, fewer input errors, and clearer expectations around taxes.
Whereas business metrics would be measured through A/B testing and post-launch data, I aimed to validate qualitative design optimizations beforehand through customer interviews.
Design success looks a little different, though. There were opportunities to reduce time and complexity for an overall better usability: a shorter, smoother checkout flow, fewer input errors, and clearer expectations around taxes.
Whereas business metrics would be measured through A/B testing and post-launch data, I aimed to validate qualitative design optimizations beforehand through customer interviews.
(Must be raw) Our shaping session with product partners to ensure the phases were doable.
Project Highlights
Project Highlights
Notable project highlights
Notable project highlights
Shaping solutions: one country at a time.
Shaping solutions: one country at a time.
Shaping solutions: one country at a time.
Later’s agile approach guided us from MVP scoping to iteration. Real progress came through open development and design collaboration: clarifying edge cases and rethinking how global address validation should work.
*For a phase 1 A/B test
In-scope
Different address form based on country selection*
Address validation & verified suggestions*
Reverse charge tax
VAT entry input and editing
Out-of-scope
Auto-submitting tax filings to government portals (e.g. HMRC)
Displaying prices dynamically in local currencies (with/without tax)
Auto-complete address search
Tax-inclusive vs. exclusive pricing
With the project scoped, one important key I kept in mind is to ensure the design will be scalable to the next country we choose to roll out the feature to.
Comparing SaaS tools showed different ways of handling reverse charge.
Comparing SaaS tools showed different ways of handling reverse charge.
Collaborating with the UX research team, we identified SaaS products that support tax reverse charge at checkout. The goal was to narrow down examples for contextual interviews to learn how test participants would perceive and confirm tax handling.
Some clearly show reverse charge in real-time, while others only confirm it on the invoice after payment.
The interviews highlighted the sensitivity of personal form fields.
The interviews highlighted the sensitivity of personal form fields.
Some users are concerned with privacy, reinforcing the risk of introducing friction that could impact conversion or data quality.
The A/B Test Guideline
Rollout
5% new UK customers
Environment
Production
Why
To validate real-world behaviour
To avoid a potentially disruptive interaction action
Duration
14 days
Given the stakes, I collaborated closely with engineering and fellow designers to plan the A/B test with a more risk-averse path.
Explorations on different affordances that display address flows for the A/B test.
Snippets of planning, wireframes, iterations, prototypes, and feedback for refinement post-shaping that led to the A/B test launch.
Experiment and Reprioritize
Experiment and Reprioritize
How did the
tests
drive progress?
drive progress?
How did the
drive progress
tests
?
Qualitative findings: trust and handling VAT information.
Interviews with customers who had submitted VAT-related chargeback tickets in the past helped us answer: how can we communicate a reverse charge and build trust during checkout?
Insight
We noticed participants felt more confident and informed when tax was removed as they're making payment.
Implication
Lack of real-time feedback creates uncertainty during checkout, weakens trust, and may deter conversion.
Quantitative validation: error reduction means faster checkout process.
We replaced in-line errors with a 2-step flow that used stronger visual affordances to guide users through address entry. This reduced friction, validated my hypothesis, and enabled the team to move forward with confidence.
Reprioritizing requirements to iterate quickly.
Our findings revealed that certain requirements weren't as high priority as we initially thought.
Requirements
Priority
Autofill for country detection
High
VAT input edit
Medium → Low – monitor
Edge-case handling for VAT-exempt regions
High → Low – monitor
Trigger VAT calculation after valid address entered
High
We've deprioritized applicable scenarios in favour of a simpler first iteration of sales tax. After launch, I plan to track and analyze usage behaviour to re-assess how deprioritized requirements can fit into future cycles.
Sales Tax: The New Experience and Impact
New address validation process
Removing in-line address validation reduced entry errors and streamlined sales tax handling on checkout. A saved address that's not recognized will fallback to the credit card address.
Charge tax
Customers based in the US, Canada, UK, and EU are now subject to tax. No more additional paperwork to claim tax during tax season.
Compliancy based on customers' region
With the mailing address entered, determining amount of tax to charge the customer becomes instant.
Reverse charge VAT on checkout and profile settings
Customers with valid VAT information can get a reverse charge by entering them on checkout or profile settings.
usability
<1 min
to save a valid address
down from 4+ minutes
<1%
avg. error occurrences
down from 50%, reducing user error and friction
18 % less
in checkout completion time
within 1 month post-launch
feature usage
52%+
existing customers updated billing address
within 2 weeks post-launch, ensuring tax-ready status
70%+
VAT input adoption
in UK and EU within 6 months, showing rising small business usage
cost savings
$1M+
sales tax collected
within 6 months post-launch, exceeding 4x initial projections
risk reduction
95%+
tax calculation accuracy
across new regions, supporting audit readiness
Impact
The launch of tax collection yielded unexpected results, surpassing success metrics we set at the start of the project.
By improving jurisdictional validation and rolling out automated VAT collection, we shifted from a high-risk situation to a compliant, audit-ready system across all targeted regions. This reduces regulatory risk and gives Later a scalable foundation for international growth.
Delivering this launch showed how design can influence business readiness at scale. By aligning with regulatory, technical, and operational goals, we created a system that supports long-term expansion and reduces risk across markets.
Learnings
Learnings
What did I learn?
What did I learn
?
Find a shared language for collaboration.
I worked closely with engineering and tax consultants. While they brought technical intuition, I focused on balancing broader workflows, compliance, and usability.
That's when I realized that each team needs its own shared language. In our case, we built that shared understanding using visual tools to map out rules, entities, and outcomes.
Compliance doesn't only mean correctness; it's also clarity.
Internal payment-related features need other ways to get customer attention.
Building for compliance often focuses on "getting the math right." However, clarity in presentation is just as critical. If users don't understand why tax is being charged, it creates mistrust despite being legally accurate.
Design has the responsibility to translate regulatory logic into transparent, trustworthy interactions.
Early validation is an investment, not a risk.
My proposal to A/B test a streamlined address form initially raised concerns about launch delays. I addressed this by sharing projected cost savings and prior experiments showing the positive impacts made with early validation.
The test confirmed improved address accuracy, reduced drop-offs, and fewer support tickets, demonstrating the value of balancing speed with quality.
New address validation process
Reduced address entry errors users were facing, and streamlined the sales tax handling during checkout. A saved address that's not recognized will fallback to the credit card address.