Skip to main content

​
Overview

In a Mexican customer’s fiscal record, tax_system is the recipient’s registered régimen fiscal code. Ask for the actual registered value. Do not infer it from a company name, the size of a business, or a code used in a tutorial.

​
How to Use It

Use tax_system on customer creation or in the embedded client object of an invoice request. On the invoice itself, use identifies the recipient’s intended Uso CFDI. The issuing team’s regime is separate configuration; changing a customer’s field does not change the issuer. Customer-body fragment, shown only to locate these two fields:
This is not a complete customer or invoice request and the values are not universal defaults. Follow Create a customer for the fiscal identity, postal code, and full request.

​
What We See

The table below identifies codes present in gigstack’s catalog. The public customer schema accepts tax_system as a string; accepting the JSON is not proof of current SAT registration, code validity for the issuance date, or a permitted Uso CFDI. Consult the SAT’s current CFDI catalogs and filling material before maintaining a fiscal validation table of your own.

​
Tax Regimes by Category

The regime label describes registration, not a reliable general-purpose entity-type classifier. For example, do not classify 621 as a small corporation or use 616 as a blanket label for tax-exempt organizations. Do not assume 626 alone identifies whether the recipient is a person or a company. Collect the actual fiscal identity.

​
Complete Tax Regimes Table

These are catalog labels, not recommendations to select or change a taxpayer’s regime. Historical codes can appear in a software catalog; check applicable validity separately.

​
Tax Regime and CFDI Usage Compatibility

Choose the usage together with the recipient’s regime and person type. A regime is not restricted to a single usage merely because one example uses it. For instance, CN01 is a payroll usage; its association with 605 does not mean a recipient under 605 can only receive payroll documents. The Uso CFDI catalog lists the compatibility groups carried by gigstack’s catalog. The SAT’s current catalog and provider validation remain the basis for fiscal acceptance. A usage code does not by itself grant a deduction.

​
Implementation Examples

​
API Request Example

For an embedded invoice recipient, put the regime inside client and the invoice’s intended use at the top level:
This fragment omits the recipient’s other required fiscal fields and all sale fields. Use the complete invoice recipe and income contract. The API does not use taxpayer, tax_regime, or entity_type in place of these fields.

​
Validation Logic

Validate the actual customer’s RFC, registered name, fiscal postal code, regime, and requested use together. Customer creation alone can succeed with fiscal validation skipped; inspect fiscal_validation when returned before issuance.

​
Common Business Scenarios

​
Important Considerations

Selecting a code in gigstack does not register a taxpayer, change its tax obligations, or establish legal eligibility for a fiscal regime. This page documents API inputs. Keep the source fiscal information available to resolve provider rejections. Use dated SAT publications for changes and code validity; this page does not provide a rolling tax-policy feed. When updating your catalog, keep its publication date and compatibility data together instead of inferring new rules from a code’s description.

​
Error Prevention

If issuance rejects the regime or use, compare the submitted values with the customer’s registered information and the actual provider message. Do not choose another regime merely to make validation pass. See Troubleshooting.