NFS-e by representation: whose CNPJ is on the invoice?

NFS-e by representation: whose CNPJ appears on the invoice?

For an international software vendor selling in Brazil through a marketplace, the CNPJ on the invoice follows from who provides the service and from who hires it, the tomador named in the NFS-e. Representation (representação, acting in the name of another taxpayer) does not change that identification. It changes who operates the issuance, on behalf of the represented party.

NFS-e is the electronic service invoice, and the CNPJ is the Brazilian corporate taxpayer registry number. Issuing an NFS-e through an API, the interface that lets systems exchange data, does not by itself settle which identity appears on the invoice. A merchant of record (MoR) is the company that stands as the seller before the end customer, with the vendor selling to it, and that seller role is what supports the invoice under the platform CNPJ. The tax treatment of that position sits outside this article. Access is not identity.

The Portal Nacional da NFS-e reported on October 31, 2026 that national issuers allow profile switching and access by representation starting November 1. The same publication covers access to the Issuance and Distribution APIs on behalf of third parties, based on the authorizations in place. That reach is the part that matters to a team issuing at volume. The Simples Nacional anticipation at the national issuer shows how another change from the same issuer already reshaped routines for companies that issue through integration.

What does the official source allow, and what remains open?

According to the Portal Nacional da NFS-e, representation may follow from an electronic power of attorney (procuração eletrônica) registered in the Brazilian Federal Revenue services or from links that already exist in the CNPJ registry base. The notice describes access and validation. It does not determine which commercial arrangement each company must adopt.

The publication covers the legal representative acting for its own company, the switch between establishments or companies that share the same CNPJ root, and acting on behalf of third parties with an electronic power of attorney valid for NFS-e services. In the web issuer, switching profiles lets a user act without ending the session or signing in again. In the APIs, the Portal also provides for access on behalf of third parties based on those authorizations.

The notice addresses the national issuers and the APIs it names, not any municipal issuer of its own. It does not define who the taxpayer is in each arrangement, and it does not say that representation transfers tax liability or relieves the seller of obligations. Topic 11 of the Emissor Público Nacional Web manual, version 1.3, dated October 31, 2026, details the feature. We checked the notice and that manual version on November 4, 2026. Because the feature went into production on November 1, the current manual version must be rechecked before implementation.

How to compare the three issuance arrangements?

Three arrangements organize issuance in a marketplace: the platform under its own CNPJ, the platform acting as representative of the seller, or the seller issuing under its own CNPJ. They differ by the CNPJ on the invoice and by who executes the issuance, and that definition reshapes the link between marketplace and service invoice.

The criterion is the CNPJ of the validated operation, not API access. A platform under its own CNPJ concentrates issuance. A platform working by representation keeps the seller's CNPJ and requires a valid authorization and a checked signature. A seller that issues keeps the CNPJ and control of the document, with verification on the platform side. The three arrangements can coexist in the same operation, one per seller, which is why control is per seller and not per platform. The table describes operating decisions to validate, not a ruling on who must issue in each deal.

The certificate used in communication is not the electronic signature of the tax document. The official notice states that validation of representation considers both elements. The guide assigns validation to the digital certificate (certificado digital) used in connections to the APIs and to the signatures of the issuers of the documents. Under representation, the issuer is the represented CNPJ, so the signature of the tax document belongs to it, and what remains is to confirm in the issuance documentation which certificate can support the connection in the name of the represented party. Custody per seller is an open implementation question, not an automatic effect of representation.

When does the invoice stay under the platform CNPJ?

Issuing under the platform CNPJ corresponds to operations where the platform is the service provider to the end customer, as the contracts and the validated operation establish. Outside that case, the platform CNPJ is not a configuration option.

The criterion is not a registry one. The platform organizes its own issuance flow and reconciles the invoices with the sales, without confusing that flow with an issuance in the seller's name. The comparison between merchant of record and own operation details the contractual design that supports that seller role.

At onboarding, the platform collects the data needed to identify the offer, the counterparty and the link to the transaction. At issuance, the technical team documents who uses the certificate and who signs. At close, finance matches the invoices issued under the platform CNPJ against the recorded sales and handles the differences.

When to use the seller's CNPJ through representation?

Representation becomes operationally viable when the validated operation requires an invoice under the seller's CNPJ, the platform wants to execute the issuance, and a verified authorization exists for that seller. The seller must be represented by an applicable link or power of attorney. The integration runs through verification of the connection certificate and of the document signature.

Three roles, not one.

That combination separates the represented seller, the representative who acts, and the person or system that actually triggers the issuance, three figures that a hurried registration usually treats as a single one. The identity on the invoice and the identity tied to the communication should not be taken as the same thing without verification. The Portal Nacional da NFS-e describes validation of representation through the digital certificate used in communication with the APIs and through the electronic signatures of the tax documents.

The operational reading is to create one record per seller with the represented CNPJ, the identification of the representative and the evidence of the link or of the power of attorney. The record also needs to state who controls the certificate used in the connection, who signs the document and how the team verifies the status and the scope of the authorization. These points are suggested controls, not a list of requirements published in the notice.

The publication does not define who should keep each certificate, nor does it fix a single signature configuration. The team must check the applicable options in the Issuance and Distribution documentation, in addition to topic 11 of the Emissor Público Nacional Web manual, version 1.3.

When to leave issuance with the seller?

Issuance by the seller is the alternative when the invoice must carry the seller's CNPJ and the platform has no validated representation for that seller. It also applies when the parties do not want the platform to execute the issuance. The seller organizes its own flow. The platform needs to agree on how it receives, identifies and checks the document.

That model keeps issuance with the seller but spreads the follow-up work across both parties. If a document is missing or the CNPJ diverges, the open item must return to the identified owner. Onboarding should establish an operational contact, the channel for sending the invoice and the way to tie it to the transaction, so the close can attribute each document to the right seller. Finance cannot assume that a sale recorded in the marketplace already has an invoice available for checking.

What to check at onboarding and at close?

Onboarding for NFS-e by representation should create a trail that the close can read: seller, CNPJ, representative, authorization and the person responsible for issuance. The finance team needs to link each invoice to the corresponding transaction and handle absences or divergences before it closes its internal reconciliation.

The control proposal below is operational. The official notice does not prescribe this close procedure, nor does it set the companies' internal deadlines.

1. Identify the parties: record seller, platform, customer and the CNPJ expected for the invoice, according to the validated operation.
2. Check the representation: verify the applicable link or electronic power of attorney, the authorized scope (services, establishments and operations covered), the validity and the evidence of that verification, without treating the commercial acceptance as automatic authorization.
3. Define communication and signature: name who answers for the connection certificate, who signs the tax document as issuer and who answers for custody, according to the approved implementation.
4. Test the transaction trail: check whether the team can relate sale, request, issuance response and invoice to the right seller.
5. Handle cancellation and replacement: confirm, before operating in the name of third parties, who can cancel or replace an invoice issued under the seller's CNPJ and within what period.
6. Reconcile and handle exceptions: compare transactions and the documents received or issued, identify failures and assign each open item to an owner.

The notice does not address cancellation or replacement of an invoice issued by representation. The guide lists both operations among the issuer features, without fixing the rule for the representative. The team must confirm in the issuance documentation, in the authorization scope and in the municipal rules who can cancel or replace the invoice and within what period, before operating in the name of third parties.

An authorization needs follow-up after the initial registration. The team must define how to notice a change of representative, of scope or of the power of attorney's validity, who stops the flow while the item is under investigation, and who confirms the resumption. At close, the question is not whether the API returned a response, but whether the invoice matching the sale was identified, whether it points to the expected CNPJ, and whether a trail exists to investigate differences.

A platform must not read an authorization failure as permission to switch the invoice CNPJ silently.

Frequently asked questions about NFS-e by representation

Representation enables access on behalf of third parties in the national APIs, under the authorizations described by the Portal Nacional da NFS-e. It does not automatically define the correct CNPJ for any sale. The operation must confirm the arrangement, the authorization and the signature implementation before issuing.

<!-- FAQPage -->

Can a platform issue for every seller with a single authorization?

No. Do not presume that. The Portal Nacional da NFS-e ties access by representation to registry links or to an electronic power of attorney valid for the services. Authorization also has scope and validity. The team must check the reach of each seller's grant before acting in that seller's name. The existence of the link is not enough.

Is the platform certificate the same as the seller certificate?

They are not the same thing. The notice separates the certificate used in communication with the APIs from the electronic signatures of the tax documents. The guide assigns those signatures to the issuers of the documents, and under representation the issuer is the represented CNPJ. No published rule requires the platform to hold custody of the seller's certificate, and the configuration must be confirmed in the applicable technical documentation.

Does representation change the tax liability of the sale?

The notice does not address transfer of tax liability, nor does it identify the taxpayer in each arrangement. It describes access by representation and its validation. The company must submit the operation and the contracts to legal and tax review, without inferring the answer from the certificate or from API access alone.

Which invoice can be cancelled or replaced when issuance is by representation?

The notice does not address the topic, and the guide lists cancellation and replacement among the issuer features without fixing the rule for the representative. Who can cancel or replace, and within what period, depends on the issuance documentation, the authorization scope and the municipal rules. The team must obtain that answer before operating in the name of third parties, because the exception has a deadline.

Does the change apply to any municipal issuer?

The official publication covers the national issuers and the Issuance and Distribution APIs named in the notice. It does not state that any municipal issuer of its own offers the same access by representation. For a flow outside that scope, the company must confirm the documentation and the conditions of the issuer it uses.

<!-- /FAQPage -->

References and Further Reading

The Portal Nacional da NFS-e notice states the reach of the feature and points to the manual and the API documentation. The references separate the official description from the operational reading proposed here. Official sources come first. Technical specifications must be checked by the integration team before defining certificates and signatures, because the current manual version may renumber the cited topic.

• Portal Nacional da NFS-e: representation and profile switching
• Emissor Público Nacional Web manual, version 1.3 dated 10/31/2026, topic 11
• Distribution API documentation
• Merchant of record in Brazil: complete guide for SaaS: how the commercial arrangement changes the invoice and the reconciliation.

The Issuance API documentation complements the references for the technical team. The technical links do not replace verification of the authorization applicable to each seller.

What is the next step for the operation?

For an operation where the seller's CNPJ has already passed legal and tax review and the platform needs to issue in that seller's name, the recommendation is to prioritize representation, starting with one seller that has a verified authorization and a defined reconciliation trail. Without that validation, do not activate the flow.

The finance owner should gather the contract, the expected CNPJ, the evidence of representation with scope and validity, and the signature and custody definition with legal and technology. If the platform cannot operate with validated representation, issuance by the seller is the alternative to assess. The platform CNPJ comes in when the platform is the service provider, not as a third option of convenience.

The Nexforce Marketplace offers a route for international vendors to sell in Latin America. For each engagement, the parties must confirm the billing design and the applicable controls. The official publication does not prove that Nexforce Marketplace already performs representation, holds certificates or issues under the seller's CNPJ.