Skip to main content

​
Overview

In a Mexican global invoice, global.months identifies the month or bimester. global.periodicity identifies how frequently the period is grouped. They are separate SAT catalogs. For a monthly global invoice covering August, the fragment is:
This is an invoice-body fragment, not a complete request. See Global invoices for the recipient and other required fields.

​
What We See

months has 18 codes: 01–12 for named months and 13–18 for named bimesters. Do not use a month code as the periodicity. For example, periodicity: "01" means daily, not January, and periodicity: "13" is not a bimester periodicity code.

​
How to Use It

Choose the reporting period that applies to the actual general-public sales and issuer. Then provide the months code, numeric year, and separate periodicity code. A subscription’s billing interval does not by itself establish eligibility to issue a global invoice or choose a two-month fiscal period.

​
Periodicity Codes Table

This section lists month and bimester codes for global.months; its existing section link is retained for older integrations. The separate periodicity codes appear under Global invoices.

​
Individual Months (01-12)

​
Bimesters (13-18)

​
Global Invoice Context

Global invoices group eligible sales to the general public; they are not a generic way to combine identified customers’ subscription invoices. Review the SAT’s current global-invoice filling guide for the permitted period, issuer regime, receiver, and transaction details. Daily and weekly periodicity codes exist. There is no blanket rule here that every global invoice must cover an entire calendar month.

​
Implementation Examples

​
API Request Example

Invoice-body fragment for a daily global invoice in August:
Invoice-body fragment for a monthly global invoice in August:
The global object is accepted by income creation and draft creation. Fields such as global_invoice, period_year, start_date, end_date, and total_transactions are not the public API’s global-invoice object.

​
Validation Logic

Validate the three fields together before issuance. The input schema requires strings for periodicity and months, and an integer for year; that type validation alone does not establish fiscal validity. The provider applies fiscal rules when stamping.

​
Common Use Cases

​
Business Considerations

Confirm eligibility for the fiscal grouping before building a scheduler. Catalog membership is not permission to use every periodicity under every regime. Keep source sale/receipt references so excluded, individually invoiced, or already-grouped sales can be reconciled.

​
Important Notes

  • global.periodicity uses SAT string codes 01–05.
  • global.months uses the month/bimester codes above.
  • Team receipt settings use different words such as day and month; do not send those in global.periodicity.
  • A global invoice uses the general-public recipient described in the global guide, including use: "S01" in that flow.

​
Error Prevention

If the provider rejects the period, inspect the actual periodicity, months, year, issuer configuration, and issuance date. Do not change the month just to suppress an error. On an ambiguous stamping response, reconcile the original attempt before retrying.

​
Integration with Other Catalogs

Use Global invoices for the general-public customer fields, Usage for use, and Payment methods for timing. The customer tax regime is distinct from the issuer’s regime and does not authorize a particular global-invoice schedule.