tax-advisor

A successful payment is not a compliant sale. This skill covers the gap.

The distinction that matters most

Two entirely different questions get conflated:

1. Who collects and remits the tax? — the merchant-of-record question.
2. Who issues the fiscal document? — the e-invoicing question.

A provider can solve the first and leave the second entirely with the merchant. In Mexico and Brazil, the second one is a legal obligation attached to the sale, and it is the one that gets forgotten because the payment works fine without it.

Merchant of record: what you actually trade

Read mor from the provider entry. When is_mor is true, that provider sells to your customer. You sell to the provider.

The trade is worth it far more often than developers assume, and it is almost always worth it for a solo developer selling digital goods across borders. Registering for VAT in seven EU countries is not a thing one person does alongside building a product.

It is usually not worth it for a domestic business selling in its own market, where it already has an accountant and pays domestic interchange.

E-invoicing: the obligation nobody generates code for

Read regions[CODE].tax.einvoice from the catalog. Where a mandate exists, the merchant must issue a specific fiscal document for each sale, in a specific format, within a specific window.

The part that bites: the data must be collected at checkout. You cannot retro-fit an RFC, a CNPJ or a tax ID after the sale — the customer has gone. If the market mandates e-invoicing and the checkout does not collect the identifier, every sale is already non-compliant.

So the recommendation is always the same shape: either use a merchant of record and the obligation is theirs, or collect the identifier at checkout and integrate an invoicing provider. There is no third option where it works itself out later.

PagoKit does not issue fiscal documents. It emits PAGOKIT_TAX_TODO.md naming the mandate, the deadline and the fields the checkout must collect.

US sales tax

Two things that are commonly got wrong:

• Economic nexus is per state, triggered by revenue or transaction thresholds that differ by state and change. It is not "do I have an office there".
• Home-rule jurisdictions — Colorado, Louisiana, Alaska and others — let localities set and administer their own rates. A state-level rate table is therefore wrong, not approximate. Where regions.US.tax.home_rule_jurisdictions is set, call an engine rather than computing a rate. That is what engine_required means in the data.

EU VAT

Digital services to EU consumers are taxed where the customer is, not where you are. OSS lets you file one return instead of twenty-seven, but you still have to determine the customer's location with two pieces of non-contradictory evidence and keep them for ten years. A merchant of record absorbs all of it.

How to answer

1. Read the region's tax block. Say what the obligation is by name.
2. Say who can discharge it: the merchant of record, an invoicing provider, or the user.
3. If the checkout must collect a tax identifier, say so explicitly and say which field.
4. Give the cost comparison in real money on their actual transaction size — the MoR premium is a concrete number, not a vibe.

Anti-patterns

• Do not give legal or tax advice. Name the obligation, name who can discharge it, and say the user should confirm with an accountant. That is the honest boundary.
• Do not say "the provider handles taxes" without checking mor.is_mor. Most do not.
• Do not conflate collecting tax with issuing an invoice.
• Do not present a state-level US rate table as correct where home-rule jurisdictions apply.
• Do not let a market with an e-invoicing mandate pass without mentioning it. A payment that works and cannot be invoiced is not a shippable integration.