Every transaction issues the right fiscal doc.
The agent watches the transaction stream and, on each settled sale, validates the buyer's tax ID, emits the correct fiscal document for the country — NF-e in Brazil, CFDI in Mexico, Factura in Argentina — and stores the PDF + XML. No end-of-month fiscal panic, no rejected invoices.
Every settled sale, a valid fiscal doc.
The agent validates the buyer's CNPJ before it cuts anything, then emits the NF-e through NFe.io, stores the PDF and XML, and hash-seals both to the originating transaction. A SEFAZ rejection comes back as a structured code the agent retries against — not a portal screenshot.
- Tax ID validated up front — bad CNPJ / RFC / CUIT never reaches SEFAZ
- Destination picks the document: NF-e in BR, CFDI in MX, Factura in AR
- PDF + XML sealed to the transaction for a reconstructable audit trail
Issue the NF-e for sale #883 and archive the PDF + XML.
Found sale #883 — validating the buyer's CNPJ first, then emitting the NF-e and sealing the docs to the transaction.
The conversation is the easy part.
Fiscal compliance is where carts die. A missed NF-e blocks a shipment; a wrong CFOP triggers a SEFAZ rejection; a bad RFC bounces a CFDI. Every country has its own document, its own validation, its own 50-odd rejection codes — and most teams discover them one failed invoice at a time.
Batch invoices at month-end and chase the rejections by hand
codespar_invoice issues on every settled transaction, in real time
Validate CNPJ / RFC / CUIT manually before each emission
codespar_kyc validates the buyer's tax ID before the doc is cut
Re-map CFOP and tax presets for every new country you enter
The right document — NF-e / CFDI / Factura — picked by destination
Store PDFs in a shared drive and hope you can find them at audit
PDF + XML stored and sealed to the transaction in the audit ledger
Pan-LATAM fiscal, on autopilot.
One meta-tool covers the region. codespar_invoice resolves the destination to the correct fiscal rail — NFe.io for Brazilian NF-e, and the CFDI / Factura providers for Mexico and Argentina — validates the buyer's tax ID through codespar_kyc first, emits the document, and stores PDF + XML against the transaction. Rejections come back as structured codes the agent can retry against, not portal screenshots.
Transaction confirmed paid
codespar_kycCNPJ / RFC / CUIT verified
KYC railcodespar_invoiceNF-e / CFDI / Factura
NFe.ioPDF + XML archived
Bound to transaction
The agent subscribes to the settled-transaction stream. For each event it runs codespar_kyc to validate the counterparty's tax ID, then codespar_invoice, which the router resolves to the country's fiscal provider. The emitted PDF + XML are stored and hash-sealed against the originating transaction so the audit trail reconstructs every fiscal obligation end to end.
A few lines. The whole loop.
const session = await codespar.sessions.create(); for await (const tx of settledTransactions) { // validate the buyer's tax ID first — bad ID, no document await session.execute("codespar_kyc", { taxId: tx.buyer.taxId }); // right document for the country, picked by destination const doc = await session.execute("codespar_invoice", { rail: tx.country === "BR" ? "nfe" : "cfdi", // NF-e · CFDI · Factura buyer: tx.buyer, items: tx.items, companyId: tx.companyId, }); await session.verificationStatus(doc.toolCallId); // PDF + XML sealed }
codespar_invoiceEmits NF-e (NFe.io), CFDI, or Factura by destination; stores PDF + XML.
codespar_kycValidates CNPJ / RFC / CUIT before the document is cut to avoid rejections.
Audit ledgerHash-seals every fiscal doc to its transaction for a reconstructable trail.
Ship it this afternoon.
Open the sandbox, point a session at your providers, and run the whole loop against real rails in minutes — not the quarter it takes to build it by hand.