> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gigstack.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Invoice Relationships Catalog (Relación entre Facturas)

> Integration guide for Invoice Relationships Catalog (Relación entre Facturas)

## 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](https://www.sat.gob.mx/minisitio/Factura/emite_materialdeayudaparafactura.htm).

## 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](/reference/postInvoicesTransfer)
before adapting an income-invoice example.

### Payment-Related

`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](/recipes/paid-later) and its explicit payment/complement
operations. See the [SAT's historical explanation of 08 and 09](https://www.sat.gob.mx/cs/Satellite?blobcol=urldata\&blobkey=id\&blobtable=MungoBlobs\&blobwhere=1461173740680\&ssbinary=true).

## Complete Relationships Table

| Code | Catalog description |
| - | - |
| `01` | Nota de crédito de los documentos relacionados |
| `02` | Nota de débito de los documentos relacionados |
| `03` | Devolución de mercancía sobre facturas o traslados previos |
| `04` | Sustitución de los CFDI previos |
| `05` | Traslados de mercancías facturados previamente |
| `06` | Factura generada por los traslados previos |
| `07` | CFDI por aplicación de anticipo |
| `08` | Factura generada por pagos en parcialidades |
| `09` | Factura generada por pagos diferidos |

## 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:

```json theme={null}
{"related_documents":[{"relationship":"01","documents":["ORIGINAL_CFDI_UUID"]}]}
```

Follow the complete [credit-note recipe](/recipes/credit-note) and
[egress contract](/reference/createInvoicesEgress). There is no `invoice` wrapper,
`relationship_type`, or `related_uuids` field in this public shape.

**Top-level request fragment** for a replacement CFDI:

```json theme={null}
{"related_documents":[{"relationship":"04","documents":["ORIGINAL_CFDI_UUID"]}]}
```

### 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

| Situation | Path to follow |
| - | - |
| Discount after a sale | [Credit-note recipe](/recipes/credit-note) with the appropriate relationship. |
| Correct an erroneous CFDI | New CFDI related with `04`; separate cancellation request for the old one. |
| Payment against a PPD income invoice | [Paid-later recipe](/recipes/paid-later), not a new income invoice using `08`. |
| Apply an advance | Confirm the SAT-specific advance procedure before choosing document types and relationships. |

## 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](/countries/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.

## Related Documentation

* [Credit-note recipe](/recipes/credit-note)
* [Cancellation motives](/guides/catalogs/cancellation_motives)
* [Payment methods](/guides/catalogs/payment_methods)
* [Shared invoice fields](/concepts/shared-fields)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.