Tax passthrough

Brazilian product invoices carry several tax groups on every item — ICMS, IPI, PIS, COFINS — each with its own regime-dependent calculation rules. stackin computes and breaks these out automatically based on the company's registered tax regime, instead of requiring every integration to reimplement Brazilian tax law.

ICMS (state-level value-added tax) is the one most sensitive to context: its rate depends on the issuer's state, the buyer's state, and whether the sale is interstate — which is exactly why recipient_address.state exists on the issue call, so the correct interstate/internal calculation can be applied without the integration knowing the rate table itself.

IPI (federal excise tax on manufactured products) and PIS/COFINS (federal social-contribution taxes) are computed per item based on the product's classification and the company's tax regime — Simples Nacional, Lucro Presumido, or Lucro Real each calculate these differently, which is resolved once at the company level, not re-specified on every call.

Presumed tax credits, when the company's regime and product qualify for them, are represented as an optional group per item rather than a separate calculation step — so a company that needs them isn't blocked, and a company that doesn't never sees the field.

This only applies to NF-e — NFS-e's service tax (ISS) is municipal and generally withheld or declared outside the document itself, so NFS-e items stay intentionally simple.

None of this makes stackin a tax advisory service — the classification codes (NCM, CFOP, CEST) still have to be correct for the specific product being sold, since they're what the calculation is based on. What stackin removes is the need to hand-implement the arithmetic and the regime-specific rules once those codes are right.