Invoices

Invoices in BDI come from CFDIs (Comprobantes Fiscales Digitales) reported to the SAT. The same record can mean very different things depending on its type and on which side of the transaction the subject sits. This page explains how to read them and how to compute monthly income.

Invoices are retrieved from GET /invoices/{identifier} — an 18-char CURP for an individual, or a 12-char RFC for a business. For a business, both invoices it issued and invoices it received are returned.

To improve invoice coverage for individuals, clients that already hold the user's RFC can pass it as the optional rfc field when creating a verification (POST /verifications). When provided, the API uses the client-supplied RFC directly and skips the internal CURP → RFC conversion.

Invoice types

Each invoice has a type field. The type determines whether the amount counts as income, and for which party.

Perspective: rfc_issuer vs rfc_receiver

The same invoice means different things depending on which side of the transaction the subject is on. When querying by CURP or RFC, always check which field the subject appears in:

• A nomina where the subject is rfc_receiver means the subject received a salary.
• An ingreso where the subject is rfc_issuer means the subject received an income.
• An ingreso where the subject is rfc_receiver means the subject bought goods or services.

Only the subject's side of each invoice is populated. The counterparty (the employer on a nomina, the client on an ingreso the subject issued, the supplier on an ingreso the subject received) comes back with rfc_* and *_name set to null. The fields are always present. In practice, the populated side tells you where the subject is. If both sides are null, the subject's RFC couldn't be determined for that identifier.

Computing monthly income

Monthly income for an identifier is the sum of two components:

1. Salary income: sum of amount for nomina invoices where rfc_receiver is the subject.
2. Self-employment income: sum of amount for ingreso invoices issued by the subject, minus the sum of amount for egreso invoices issued against those ingresos by the same RFC.

monthly_income =
    Σ nomina.amount  (subject as receiver)
  + Σ ingreso.amount (subject as issuer)
  − Σ egreso.amount  (subject as issuer)

This formula applies to both individuals and businesses. For businesses, salary income is typically zero — they receive income through ingreso invoices, not nomina.

pago invoices: how to read them

pago invoices are SAT's "Recibo Electrónico de Pago" — a complement issued when a customer pays an invoice that was originally issued under deferred or installment payment terms (PPD). The pago CFDI itself does not represent new revenue; it documents a payment against a previously-issued invoice.

Because of this, per SAT spec the top-level amount, subtotal, total_taxes_transferred, and total_taxes_retained on a pago CFDI are zero or near zero. The actual payment value (amount paid, payment date, payment method) lives in a separate node called "Complemento de Pagos," which is not exposed in the default /invoices response.

To retrieve payment details, pass include_payment_info=true on the request. Each invoice will include a payment_info[] array of payment records, and each entry contains a nested payment_relations[] array linking that specific payment to the ingreso invoices it was applied to.

Use this when:

• Validating whether PPD invoices have been paid.
• Measuring payment behavior (timeliness, partial payments).
• Reconciling invoiced revenue against cash collected in a given period.

Common pitfalls

• Summing pago as income → double-counting. pago documents a payment, not new revenue.
• Treating egreso as a generic expense → understates income. egreso is a correction to a previously issued ingreso, not an arbitrary debit.
• Ignoring perspective: a nomina where the subject is rfc_issuer is not received salary — the subject paid it.
• Treating self-issued CFDIs (subject on both sides) as non-income → they are income.
• Expecting incomes / deductions on ingreso or pago invoices → those fields are nómina-specific.
• Aggregating across mixed currencies without normalizing (currency field).

Field reference

The same invoice object is returned for individuals and businesses. Nómina-specific fields are only populated for nomina invoices.

incomes and deductions

For nomina invoices, the response includes incomes and deductions arrays with the line-item breakdown (Percepciones and Deducciones in SAT terminology). For other types, both arrays are empty.

Each item has amount, currency, and a free-form detail label (e.g., Sueldo, Aguinaldo, ISR, IMSS). Items can also include key and type SAT codes that identify and group the concept.

line_items

For ingreso and egreso invoices, the response can include a line_items array with the products or services included in the invoice.

Use line_items to understand what was billed or corrected, but use the top-level amount when computing income totals.

invoice_relations

For ingreso and egreso invoices, the response can include an invoice_relations array with references to related fiscal documents.

payment_info

For pago invoices, passing include_payment_info=true adds a payment_info array with one entry per payment recorded in the CFDI's "Complemento de Pagos". Each entry carries its own payment_relations array linking that payment to the ingreso invoices it was applied to.

Each entry of payment_relations:

Job risk (nomina)

The SAT defines occupational risk as follows: