Skip to main content

​
Overview

For Mexican CFDI, related_documents records how a new document refers to earlier CFDIs. Supply the previous documents’ fiscal UUIDs. A relationship alone does not cancel an invoice, issue a refund, or record money received.

​
What We See

The shared invoice schema accepts an array of objects, each containing relationship and documents. The codes below are the gigstack catalog labels. Verify the appropriate code and document-type combination against the SAT’s filling guides.

​
How to Use It

For a discount documented by an egress CFDI, the tested recipe uses relationship 01 and the original income UUID. For replacing an erroneous CFDI, the new document uses relationship 04; cancelling the old document is a separate operation with its own motive.

​
Relationship Types and Codes

​
Adjustment Documents

01 and 02 identify credit/debit-note relationships. The linked document, its amounts, and the transaction establish the actual adjustment; setting a relationship string alone changes no balance and initiates no processor refund.

​
Substitution and Returns

03 describes returned goods in relation to prior invoices/transfers. 04 describes substitution of prior CFDIs. Relationship 04 is not cancellation motive 04.

​
Goods Movement

05 and 06 describe links between transfer and invoicing documents. Check the applicable document types and the transfer contract before adapting an income-invoice example. 07 describes advance application. Codes 08 and 09 appear in the catalog, but must not be used as a shortcut for the ordinary payment-complement flow. Older SAT guidance associates them with a specific transitional rule for prior CFDIs. For the current tutorial, use Paid later and its explicit payment/complement operations. See the SAT’s historical explanation of 08 and 09.

​
Complete Relationships Table

​
Implementation Examples

​
API Request Examples

Top-level request fragment for a related credit note. Replace the placeholder with the actual original UUID; the full egress request also needs the client, items, currency, and fiscal fields:
Follow the complete credit-note recipe and egress contract. There is no invoice wrapper, relationship_type, or related_uuids field in this public shape. Top-level request fragment for a replacement CFDI:

​
Validation Logic

Resolve each UUID from an issued document, verify the intended issuer and recipient, and inspect the final XML relationship. Schema acceptance of a string does not validate the fiscal suitability of that relationship.

​
Common Business Scenarios

​
Document Chain Examples

​
Credit Note Chain

Original income UUID → new egress UUID referring to the original. Preserve both IDs and inspect the new document’s relationship and amounts.

​
Substitution Chain

Original UUID → replacement UUID with relationship 04 → cancellation request for original with motive 01 and the replacement UUID. Verify cancellation separately.

​
Advance Payment Chain

A catalog code does not provide a complete advance workflow. Follow the applicable SAT advance procedure and confirm which documents have already been issued before constructing the next one.

​
Transfer to Sale Chain

Preserve the UUIDs of the transfer and resulting invoice. The relationship records their fiscal link; it does not itself create shipping or inventory movements.

​
Important Considerations

The catalog applies to Mexico. Colombia uses country-specific provider behavior; SAT relationship meanings are not a universal cross-country contract.

​
Error Prevention

Do not substitute draft IDs or payment IDs for fiscal UUIDs. Do not create a duplicate income CFDI to acknowledge a PPD payment. After a timeout, reconcile the first attempt before issuing a second credit note or replacement.