Document Components

Relevant source files

• lines.go
• parties.go
• parties_test.go
• taxes.go
• taxes_test.go

This page provides an overview of the major structural building blocks that comprise a CFDI XML document. These components are constructed from GOBL invoice data and assembled into a hierarchical XML structure that conforms to the Mexican SAT CFDI 4.0 schema.

For details on the core conversion orchestration and validation, see Core CFDI Engine. For information about document extensions such as stamps and addendas, see Document Extensions and Features.

Purpose and Scope

A CFDI document consists of several mandatory and optional components that capture different aspects of an invoice transaction. The core components are:

• Parties: Supplier (Emisor) and customer (Receptor) information
• Line Items: Product/service details (Conceptos)
• Taxes: Tax calculations at both document and line level (Impuestos)
• Payment Information: Payment method and form codes
• Extensions: Optional stamps, related documents, addendas, and complements

This page describes how these components are represented in code and how they fit together. Detailed documentation for each component type is available in the child pages:

• Party Management: see Party Management (Emisor and Receptor)
• Line Items: see Line Items (Conceptos)
• Tax Processing: see Tax Processing System
• Payment Information: see Payment Information

Component Architecture

XML Document Structure Hierarchy

Sources: parties.go11-36 lines.go9-29 taxes.go12-43

This diagram shows how the main structs nest within the CFDI XML structure. The Document struct (defined in the core conversion module) contains top-level components, which in turn contain nested sub-components. Tax data appears at both document and line levels with identical structures.

Component Creation Flow

Sources: parties.go38-96 lines.go32-64 taxes.go54-104

Each component type has a dedicated constructor function that extracts relevant data from the GOBL invoice structure and transforms it into CFDI-compliant format. These functions are invoked by the main Convert function during the document assembly process.

Core Component Types

Party Components

The party components represent the supplier and customer entities in a transaction:

Component	Struct	Constructor	Purpose
Supplier	Emisor	newEmisor()	Issuer information with RFC and fiscal regime
Customer	Receptor	newReceptor()	Recipient information with postal code and CFDI use
Third Party	ThirdParty	newThirdParty()	Optional seller-on-behalf information

Key Fields:

• Emisor: Rfc, Nombre, RegimenFiscal parties.go12-16
• Receptor: Rfc, Nombre, DomicilioFiscalReceptor, RegimenFiscalReceptor, UsoCFDI, NumRegIdTrib (foreign), ResidenciaFiscal (foreign) parties.go19-27
• ThirdParty: RFC, Name, FiscalRegime, PostCode parties.go31-36

The newReceptor function handles three scenarios: simplified invoices (generic public customer), foreign customers, and standard Mexican business customers parties.go60-96 For detailed party processing logic, see Party Management (Emisor and Receptor).

Sources: parties.go11-96 parties_test.go11-65

Line Item Components

Line items represent the products or services being invoiced:

Component	Struct	Constructor	Purpose
Line List	Conceptos	newConceptos()	Container for all line items
Individual Line	Concepto	newConcepto()	Single product/service entry

Key Fields:

• ClaveProdServ: SAT product/service code
• NoIdentificacion: Item reference
• Cantidad: Quantity
• ClaveUnidad: SAT unit of measure code
• Descripcion: Item description
• ValorUnitario: Unit price
• Importe: Line total (quantity × price)
• Descuento: Discount amount (optional)
• ObjetoImp: Tax applicability indicator ("01" = not subject to tax, "02" = subject to tax)
• Impuestos: Line-level tax breakdown
• ThirdParty: Third-party seller information (optional)

Sources: lines.go9-72

The ObjetoImp field is computed by lineSubjectToTax() which returns "02" if the line has any taxes applied, otherwise "01" lines.go66-71 For detailed line processing including SAT code mapping, see Line Items (Conceptos).

Tax Components

Tax information appears at two levels in the document:

Level	Component	Purpose
Document	Impuestos	Aggregated tax totals for entire invoice
Line	ConceptoImpuestos	Tax breakdown for individual line item

Both levels share common structures:

Sources: taxes.go12-43

Tax Categories:

The taxCategoryMap translates GOBL tax categories to SAT tax codes taxes.go46-52:

GOBL Category	SAT Code	Description
mx.TaxCategoryISR	"001"	Income tax (ISR)
tax.CategoryVAT	"002"	Value-added tax (IVA)
mx.TaxCategoryRVAT	"002"	Retained VAT
mx.TaxCategoryIEPS	"003"	Special tax on production/services
mx.TaxCategoryRIEPS	"003"	Retained IEPS

Impuesto Struct Fields:

• Base: Taxable amount
• Importe: Calculated tax amount
• Impuesto: SAT tax code ("001", "002", "003")
• TasaOCuota: Tax rate or quota
• TipoFactor: Factor type ("Tasa", "Cuota", "Exento")

For complete tax calculation logic including special IEPS handling, see Tax Processing System.

Sources: taxes.go12-52

Payment Information Components

Payment information is stored directly in the Document struct rather than in a separate component:

Field	Type	Purpose
MetodoPago	string	Payment method code (PUE = single payment, PPD = partial/deferred)
FormaPago	string	Payment form code (01 = cash, 03 = transfer, 04 = credit card, etc.)

These values are determined by the newMetodoPago and newFormaPago functions, which analyze payment advances and invoice totals to select appropriate codes. For detailed payment determination logic, see Payment Information.

Sources: cfdi.go162-201 (referenced in architecture diagrams)

Component Relationships

Data Flow Between Components

Sources: taxes.go54-104 taxes.go180-215 lines.go32-64

This diagram illustrates the parallel processing of document-level and line-level data. Document-level taxes are calculated from invoice totals, while line-level taxes are computed for each individual line item. Both processes use shared helper functions like newImpuesto() to ensure consistent tax entry formatting.

Tax Aggregation and Merging

A special case in tax processing is the handling of IEPS line charges, which must be merged into the document-level tax totals:

Sources: taxes.go106-143

The taxesAddLineCharges function iterates through all line charges (currently only IEPS charges), creates tax entries for them, and either merges them into existing tax totals (if matching tax code and rate exist) or appends them as new entries taxes.go106-143 This ensures that IEPS charges, which appear at the line level in GOBL, are properly aggregated into document-level tax totals as required by CFDI.

Constructor Function Reference

The following table summarizes the primary constructor functions for each component type:

Function	Input	Output	Location
newEmisor()	*org.Party	*Emisor	parties.go38-45
newReceptor()	*org.Party, string	*Receptor	parties.go60-96
newThirdParty()	*org.Party	*ThirdParty	parties.go47-58
newConceptos()	[]*bill.Line, *bill.Ordering	*Conceptos	lines.go32-43
newConcepto()	*bill.Line, *bill.Ordering	*Concepto	lines.go45-64
newImpuestos()	*bill.Totals, []*bill.Line, currency.Code	*Impuestos	taxes.go54-104
newConceptoImpuestos()	*bill.Line	*ConceptoImpuestos	taxes.go180-215
newImpuesto()	cbc.Code, *tax.RateTotal, currency.Code	*Impuesto	taxes.go160-178
newImpuestoFromCombo()	*bill.Line, *tax.Combo	*Impuesto	taxes.go217-242
newImpuestoFromLineCharge()	*bill.Line, *bill.LineCharge	*Impuesto	taxes.go244-272

Sources: parties.go38-96 lines.go32-64 taxes.go54-272

These constructor functions are invoked by the main cfdi.Convert function during the document assembly process. Each function is responsible for extracting relevant data from GOBL structures, performing necessary transformations (such as code mapping and rounding), and returning properly formatted CFDI component structs.

Validation and Constraints

Components must adhere to specific validation rules to produce valid CFDI XML:

Emisor Requirements:

• Must have valid RFC (tax ID)
• Must specify fiscal regime (RegimenFiscal)

Receptor Requirements:

• Must have RFC or use generic/foreign codes
• Must specify postal code (DomicilioFiscalReceptor)
• Must specify CFDI use code (UsoCFDI)
• Foreign customers require NumRegIdTrib and ResidenciaFiscal

Concepto Requirements:

• Must have SAT product/service code (ClaveProdServ)
• Must have SAT unit code (ClaveUnidad)
• Must have valid tax applicability indicator (ObjetoImp)
• Quantity and price must be positive

Impuesto Requirements:

• Tax codes must match SAT catalog ("001", "002", "003")
• Rates must have 6 decimal precision
• Amounts must match currency precision (2 decimals for MXN)
• TipoFactor must be "Tasa", "Cuota", or "Exento"

For validation logic executed before component construction, see Validation and Support Checking.

Sources: parties.go38-96 lines.go45-64 taxes.go160-178

Summary

The CFDI document is composed of several interdependent components that work together to create a complete, SAT-compliant XML invoice. The core components are:

1. Parties (Emisor, Receptor, ThirdParty) - Entity information
2. Line Items (Conceptos, Concepto) - Product/service details
3. Taxes (Impuestos, ConceptoImpuestos, Impuesto) - Tax calculations
4. Payment Info (MetodoPago, FormaPago) - Payment method codes

Each component is constructed from GOBL invoice data using dedicated constructor functions that handle data transformation, code mapping, and precision adjustments. The components are assembled into a hierarchical structure that mirrors the CFDI XML schema, with taxes appearing at both document and line levels.

For in-depth documentation on each component type, refer to the child pages listed in the table of contents.