Invoicing in Mexico is not a printing problem, it is a validation problem. Every sales invoice, credit memo and payment has to be built as a CFDI 4.0 XML, signed with your CSD certificate, stamped by an authorised PAC and accepted by the SAT before it is legally a document at all. Dynamics 365 Business Central gives you a solid posting engine, dimensions and clean customer and item master data — but out of the box it has no concept of a UUID, a RegimenFiscal, a UsoCFDI, a ClaveProdServ, a payment complement, or a cancellation that has to be requested, acknowledged and sometimes rejected by the buyer. Teams end up posting in Business Central and then re-keying the same invoice into a PAC portal or a spreadsheet bridge, which is where mismatched totals, wrong tax codes and untraceable cancellations start.

We build a Business Central AL extension that closes that gap inside the system where the invoice is already posted. Table extensions carry the Mexican fiscal fields on Customer, Item, company setup and the posted sales documents — RFC, tax regime, postal code of issue, UsoCFDI, ClaveProdServ, ClaveUnidad, payment method and payment form. Page extensions surface them next to the fields your finance team already uses, so the data lives on master records rather than being typed per invoice. A codeunit layer composes the CFDI 4.0 XML from the posted document, applies your tax mapping (IVA at the applicable rate, IVA retenido, ISR retenido, exempt and zero-rated lines) and calls your PAC's web service to stamp it. Event subscribers on the standard posting codeunits pick the document up automatically, and a job queue entry retries anything that failed transiently instead of leaving it stranded.

Stamping is only half the lifecycle, so the extension models the rest of it. The stamped UUID, the SAT seal, the certificate number and the timestamp are written back to the posted document, and both artefacts come from that one posting: the signed XML for the SAT and a human-readable PDF with the QR and the digital-stamp block for the customer. Cancellations follow the current SAT flow — a cancellation reason and, where required, the substituting UUID — with the request, the acknowledgement and the buyer's acceptance or rejection recorded as state on the document rather than as a note in a comment line. When a PAC rejects a stamp, the error code and message land on a correction worklist so an accountant can fix the RFC, the regime or the product key and resubmit, with every attempt kept in an audit log. XML, PDF and response payloads are archived against the document so a SAT audit can be answered from Business Central instead of from someone's mailbox.

Everything is packaged as a proper AL app with its own permission sets, so the accountant who stamps, the clerk who corrects rejections and the controller who cancels can be separated. We target current Business Central release waves and can deliver as a per-tenant extension or, where you want it in your own AppSource pipeline, as an app built to those requirements. On SaaS the PAC is called over outbound HTTP with credentials held in isolated storage; on-premises we work with your proxy and certificate handling. API pages exposed over REST API v2.0 / OData v4 let a Power Automate flow, a Dataverse-connected app or a customer portal read stamp status and pull the signed XML without anyone touching the database.

This is build-to-order, and we are explicit about that: there is no instant download. You request a quotation, we run a scoping call to pin down your PAC, your Business Central version and deployment, your tax and product-key mapping, and which document types are in scope. We then build the extension against your setup, install it on a sandbox for UAT with your own certificates and your PAC's test environment, and go live with you. Typical delivery is two to four weeks from confirmed scope. You receive the AL source, the git repository, documentation and a post-go-live support window — the extension is yours, not a licence you rent.