Mexico CFDI E-Invoicing & Complemento de Pago

A Mexican invoice is not a document you print, it is a document that has been stamped. Until the XML has passed through an authorised certification provider and come back carrying a Timbre Fiscal Digital with a UUID, nothing has legally happened, no matter how correct the NetSuite Invoice looks. Then the requirements keep going: a PPD invoice is not complete until every payment against it produces its own payment complement referencing the original UUID and the running balance; a cancellation is not a status flag but a request with a reason code, sometimes a replacement folio, and sometimes the customer's acceptance; and if goods move, a transport complement rides along with the document. Teams that started with a light localisation usually discover this in stages, and the gap gets filled with spreadsheets, a portal login and one person who understands the catalogue codes.

What ECOSIRE builds

ECOSIRE builds this app for you. It is not a product you download and it is not running anywhere until we build it for your account. After a scoping call we issue a fixed quote, then develop against a sandbox refresh of your real data, install into your sandbox for sign-off, and promote to production when your finance team is satisfied with documents they have stamped themselves.

The implementation is native NetSuite work: SuiteScript 2.1 User Event scripts for validation, Map/Reduce for batch issuance, Scheduled scripts for retries and reconciliation, Suitelets for the operator screens, RESTlets where an external system needs to trigger issuance, and SuiteFlow for the cancellation and approval paths. Catalogues, mappings and the full call log live in custom records. Delivery is an SDF project installed as an unmanaged bundle that stays yours, including the source.

Issuance and stamping

A builder module composes the CFDI XML from the transaction: issuer and receiver blocks with RFC, tax regime and the receiver's fiscal postal code; the CFDI use; currency and exchange rate; payment form and payment method; and a line block per item carrying the product or service key, the unit key, the tax-object indicator and the transferred or withheld taxes. Values come from mapped fields on the Item, Customer and Subsidiary records, not from free text, so the same invoice cannot be built two different ways by two different users.

Sealing with your Certificado de Sello Digital and submission for stamping are handled through the connection model your chosen authorised certification provider supports, with credentials held in a permission-restricted custom record. When the stamp returns, the UUID, stamp date, certificate serial and the provider's response are written to custom transaction body fields, the signed XML is stored in a dedicated File Cabinet folder and linked to the transaction, and the printable representation is rendered from an Advanced PDF/HTML template carrying the verification QR code and the required legends. Failures are parsed into readable messages on a child custom record so the person fixing them sees the offending field rather than a numeric code.

Payment complements, cancellations and credit notes

PPD invoices are tracked from the moment they are stamped. When a Customer Payment is applied, a scheduled process assembles the payment complement, carrying each related document with its previous balance, amount paid, remaining balance and instalment number, and links the resulting UUID back to both the payment and the original invoice. Partial payments, multi-invoice payments and foreign-currency payments are all handled from the applied lines on the NetSuite Payment record rather than from a manual worksheet.

Cancellation is modelled as a workflow, not a checkbox. The user selects a reason, supplies a replacement folio where the reason requires one, and the request goes to the provider; the resulting acceptance, rejection or pending state is written back to the transaction and surfaced in a saved search so nothing sits in limbo. Credit notes are issued as their own CFDI with the correct relationship type pointing at the document being corrected, so the relationship survives in the XML and not only in NetSuite.

Carta Porte and receiver-specific addenda

Where goods move under your own or a contracted transport, the transport complement is built from a Suitelet-driven form backed by custom records for vehicles, operators, permits, routes and locations, with the goods lines derived from the Item Fulfilment rather than rekeyed. If specific customers require an addendum in their own format, we generate it from a template-driven module keyed on the customer record, so adding a new receiver format later is a configuration and template exercise instead of a rewrite.

Who this is for

Mexican entities on NetSuite that have outgrown a light localisation, and multinational groups where Mexico is one OneWorld subsidiary and the group close cannot wait on a local spreadsheet. It suits shared service centres that raise Mexican documents from another country, controllers who need every UUID visible against the transaction that produced it, and manufacturers or distributors whose shipments require the transport complement.

How delivery works

1. Scoping call. We review your transaction types, item catalogue, customer master, tax setup, certification provider, volumes and which complements apply. 2. Fixed quote. You get a written scope with the field-by-field mapping, optional modules priced separately, and a delivery date. No work starts until you accept it. 3. Build. Development runs against a sandbox refresh of your account so we work with your real master-data shapes. 4. Install in test. The bundle is installed in your sandbox and connected to your provider's test environment. Your team stamps, cancels, pays and reverses real scenarios and signs off. 5. Production. We install into production in a window you choose, migrate configuration and credentials, and stand by through the first live stamping cycle. 6. Support window. A defined post-go-live support period is included in the quote, covering defects, catalogue updates and support through your first month-end.

What we do not claim

This is a build, not a download, and there is no trial version because nothing exists for your account before the build. We are not a certified partner of any software vendor, we do not resell anyone's connector, and we do not act as a certification provider ourselves; your relationship with your provider stays yours and we integrate with it. We do not give tax advice: your tax advisors decide which keys, uses, regimes and reason codes apply to your transactions, and the build makes those decisions data rather than code so they can change without a developer. Catalogue and schema updates during the support window are covered; structural changes afterwards are quoted as changes.