stackin
Back to blog
Solutions

Issue NFS-e

Service invoice issuance through the national NFS-e system — no per-city integration required.

NFS-e (Nota Fiscal de Serviços Eletrônica) is the electronic invoice for services. Unlike NF-e, a service has no tax classification code — an NFS-e item only needs a description and an amount.

stackin issues through Brazil's national NFS-e system (ADN), so the same integration works regardless of which municipality the issuer is registered in — no per-city webservice to onboard separately.

Cancellation, consultation, and history work the same way as NF-e: one access key, one dashboard, one submission timeline.

That national layer is the reason NFS-e integrations are usually harder to build than NF-e ones: historically, every city ran its own webservice, its own XML schema, and its own quirks, which meant a company selling services nationally needed a separate integration per municipality it operated in.

stackin's job is to absorb that variance entirely — the request you send doesn't change based on the issuer's city, and the response shape is identical to NF-e's wherever possible, so a team already integrated with product invoices can add service invoices without learning a second mental model.

Service tax (ISS) is municipal, not federal, and unlike NF-e's tax groups it's typically withheld or declared outside the issuance call itself — which is why an NFS-e item stays intentionally minimal instead of carrying the same tax-classification burden as a product line item.

As with NF-e, the digital certificate and the issuer's registration data are resolved from the company configuration, not passed on the call — the only per-item decision is what the service was and how much it cost.

See NFS-e issuance for how that API surface fits into the rest of stackin.