Reading Invoices

How to interpret invoice data returned by the API and compute income correctly from it.

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.


Invoice types

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

CodeCounts as income?For whom
nominaYesThe rfc_receiver (the employee being paid)
ingresoYesThe rfc_issuer (the party selling goods/services)
egresoNo, it is a correctionReduces a previously issued ingreso from the same RFC
pagoNo, it is a collection complementDocuments the actual payment of a previously issued ingreso

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.

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.

incomes and deductions arrays

For nomina invoices, the response includes incomes and deductions arrays with the line-item breakdown (Percepciones and Deducciones in SAT terminology). Each item has amount, currency, and a free-form detail label (e.g., Sueldo, Aguinaldo, ISR, IMSS).

For ingreso, egreso, and pago invoices, both arrays are returned empty. The SAT structure for these types is based on line items ("Conceptos") and tax breakdowns, not Percepciones/Deducciones.


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

For the full invoice field list (per identifier type), see: