What changed in CFDI 4.0
CFDI 4.0 is the current version of the digital tax document and replaces the 3.3 scheme used for years. The SAT's goal with this update was to strengthen consistency between the issuer's data, the recipient's data and the information the taxpayer has on record. This means it is no longer enough to enter an RFC: the document requires the recipient's data to match their current tax status exactly.
For anyone invoicing from SAP Business One, the impact is operational. Business partner master data must contain accurate, up-to-date tax information, because any discrepancy results in a rejection from the authorized PAC. The most relevant fields and changes the standard introduces are:
- Recipient's tax regime: now mandatory and must match the regime the client has registered with the SAT.
- Recipient's name and tax domicile: must be captured exactly as they appear on the proof of tax status, including the postal code.
- Tax object: each line item must indicate whether the operation is subject to tax or not.
- Stricter validations: the SAT and the PAC verify the match between RFC, name, postal code and regime before stamping.
- Greater requirements for complements (such as payments and Carta Porte), subject to each company's operation.
Options to stamp CFDI in SAP Business One
Broadly speaking, there are two paths to issue CFDI from SAP Business One. The first relies on SAP B1's standard output capabilities combined with basic developments or connectors to a PAC. The second incorporates a specialized add-on that integrates natively with SAP Business One and manages the full stamping cycle against the authorized PAC.
The native or custom-development approach tends to show limitations as the operation grows: maintenance depends on a specific vendor or consultant, updates to Anexo 20 and the complements require reprogramming, and handling addendas, the payment complement or Carta Porte can become costly. In addition, pre-stamping validation tends to be limited, which increases rejections.
A specialized add-on like SIGI CFDI, by SIGITEC, is designed to operate within the logic of SAP Business One and connect to an authorized PAC, so that stamping, XML retention and PDF generation happen without leaving the system. This makes it easier to keep CFDI 4.0 validations current, manage complements and addendas, and reduce the technical support burden. The exact scope depends on your SAP B1 version and the configuration defined during discovery.
Payment complement 2.0 in SAP B1
The payment complement 2.0, also known as the Electronic Payment Receipt, is a specific CFDI that documents the receipt of payments when the operation is not settled in a single payment. As a general rule it applies when you invoice with an installment or deferred payment method (PPD): you first issue the invoice and, as you receive payments, you generate the corresponding complement to inform the SAT how and when the operation was settled.
In SAP Business One, generating the complement correctly means linking the payment received to the original invoice through its UUID, declaring the amount, the currency and, where applicable, the exchange rate, while respecting the 2.0 version validations. If these data are not related precisely, the PAC may reject the document or, worse, leave payments incorrectly reported.
With an add-on like SIGI CFDI, the payment complement draws on the information that already lives in SAP B1, which reduces manual entry and the risk of error. The exact way the flow is configured depends on your operation and should be validated during discovery; when in doubt about the tax treatment of a payment, it is best to confirm it with your accountant.
Addendas: when you need them
An addenda is additional information added to the CFDI at the recipient's request which, unlike the SAT complements, is not part of the tax standard: it responds to the client's commercial or administrative requirements. It does not change the fiscal validity of the document, but it is often essential for the supplier to get paid.
Addendas are common when you invoice large chains, retail or corporations that operate with their own receiving portals. Each client may require its own format and set of data (purchase order number, supplier identifiers, logistics references, among others), so there is no single addenda: it is configured case by case according to the recipient.
In SAP Business One, handling addendas means mapping the data each client requires into the structure its portal demands and embedding it in the XML at the time of stamping. SIGI CFDI can contemplate addenda configuration depending on the client and the project scope; the specific catalog of supported addendas and their parameterization is defined during discovery.
Common errors when stamping in SAP B1 and how to avoid them
Most rejections when issuing CFDI 4.0 from SAP Business One do not come from the system, but from inconsistencies in master data or fiscal configuration. Identifying them early prevents invoicing interruptions and rework at closing. These are the most frequent errors and how to prevent them:
- Invalid RFC: entering the recipient's RFC without verifying it against their proof of tax status. Validate the RFC before invoicing.
- Incomplete recipient data: name, postal code or tax domicile that do not match the SAT record. Keep business partners in SAP B1 up to date.
- Incorrect tax regime: assigning the client a regime other than the one they have registered causes immediate rejection.
- PAC rejection: XML structure errors or unaddressed Anexo 20 validations; it is best to validate before sending to stamp.
- Double stamping: issuing the same document twice due to poorly controlled retries; use controls that prevent duplicating the UUID.