Argentina Electronic Invoicing: A Guide to Factura Electrónica

Every invoice issued in Argentina must be electronically authorized before it carries legal validity. This is not a post-hoc reporting requirement — Argentina operates a pre-clearance model where the tax authority validates each invoice in real time and assigns a CAE (Código de Autorización Electrónico) before the document can be delivered to the buyer. Among Latin American clearance systems, only Mexico's CFDI framework rivals Argentina's in scope, routing every invoice through certified intermediaries (PACs) before it gains fiscal validity. Without a CAE, an invoice has no fiscal standing.

The authority behind this system is ARCA (Agencia de Recaudación y Control Aduanero), which replaced the former AFIP (Administración Federal de Ingresos Públicos) in October 2024 under Decree 953/2024. ARCA inherited AFIP's entire electronic invoicing infrastructure — technical specifications, web services, and taxpayer obligations carried over without interruption. Legacy documentation and technical guides still reference AFIP; prior AFIP resolutions remain in force unless explicitly superseded by new ARCA resolutions. The broader trajectory of Argentine tax modernization reinforces this direction: the World Bank's 2025 announcement of a US$300 million tax modernization project for Argentina targets enhanced tax administration through ARCA, including simplified procedures and pre-filled digital tax forms.

Argentina's electronic invoicing system revolves around several core components:

Lettered invoice types (A, B, C, M, T, E) determined by the tax registration status of both the issuer and the recipient. The correct letter is not optional — issuing the wrong type triggers penalties and rejection by the buyer's tax system.
XML-based electronic documents submitted to ARCA's web services for authorization. Each submission returns a CAE and an expiration date, which must appear on the printed or PDF version of the invoice.
Mandatory QR codes on all invoices since December 2020, encoding key invoice data in a standardized format that ARCA can verify independently.
Integration with the Libro IVA Digital, Argentina's automated VAT ledger system that cross-references issued and received invoices to pre-populate tax returns — closing the loop between invoicing and tax compliance.

Invoice Types A, B, C, M, T, and E Explained

The first decision in issuing an Argentine invoice is selecting the correct letter type. Each invoice carries a letter designation (A, B, C, M, T, or E) that controls how VAT is treated on the document, what withholding obligations apply, and which data fields are mandatory. The letter is determined by two factors: the tax registration status of the issuer and the tax registration status of the recipient.

Before using the decision matrix below, you need to understand two foundational tax categories in Argentina's system:

Responsable Inscripto refers to a taxpayer registered in the general VAT regime. These businesses charge VAT on their sales, claim input VAT credits on their purchases, and file monthly VAT returns. Most medium and large businesses fall into this category.

Monotributista refers to a taxpayer enrolled in the Monotributo (simplified tax regime), which bundles income tax, VAT, and social security into a single fixed monthly payment based on revenue brackets. Monotributistas do not itemize VAT on their invoices and cannot claim VAT input credits. This regime is designed for small businesses, freelancers, and sole proprietors below certain revenue thresholds.

Invoice Type Decision Matrix

Issuer Status	Recipient Status	Invoice Type	VAT Treatment
Responsable Inscripto	Responsable Inscripto	A	VAT itemized separately on the invoice
Responsable Inscripto	Final consumer or VAT-exempt entity	B	VAT included in the total price (not broken out)
Responsable Inscripto (under fiscal monitoring)	Responsable Inscripto	M	VAT itemized; mandatory withholding legend applied
Monotributista	Any recipient	C	No VAT itemization permitted
Hotels / tourism operators	Foreign tourists	T	VAT refund mechanism for eligible purchases
Any taxpayer	Foreign buyer (export)	E	Zero-rated VAT (export invoice)

What Each Type Means in Practice

Types A, B, and C cover the standard domestic scenarios. Type A is the B2B invoice between two Responsable Inscripto entities, with VAT itemized so the recipient can claim input credits. Type B applies when the recipient is a final consumer or VAT-exempt, embedding tax in the price. Type C is issued by Monotributistas to any recipient, with no VAT itemization permitted.

Type M was introduced as a monitoring mechanism for newly registered Responsable Inscripto taxpayers or those flagged by the tax authority for compliance risk. It functions like a Type A invoice but carries a withholding legend requiring the recipient to withhold a portion of the VAT and remit it directly to the tax authority. General Resolution 5762 eliminates Type M invoices effective December 2025, replacing them with standard Type A invoices. Businesses currently issuing or receiving Type M documents should prepare for this transition.

Type T serves a narrow but specific purpose: enabling foreign tourists to recover VAT on eligible purchases from hotels and tourism operators. The invoice triggers a refund process administered at departure points.

Type E is the export invoice, used whenever the buyer is located outside Argentina. These invoices carry zero-rated VAT, consistent with the destination principle applied in international trade. Type E invoices have their own required fields, including the destination country and the customs documentation reference where applicable.

CAE Authorization: How Real-Time Invoice Clearance Works

An Argentine invoice without a CAE is not a legal document. The CAE (Código de Autorización Electrónico) is what transforms a draft invoice into a fiscal document recognized by ARCA and enforceable under Argentine tax law.

The authorization workflow operates as a real-time clearance model. The issuing party submits structured invoice data to ARCA's web services, ARCA validates the submission against its rules, and if everything checks out, it returns a unique CAE along with an expiration date. The entire exchange happens programmatically, typically completing in seconds.

The Technical Workflow

The process follows a defined sequence:

Authentication. The issuer authenticates against ARCA's web services using a Digital Certificate (Certificado Fiscal Digital). This certificate must be generated through ARCA's portal and linked to the taxpayer's CUIT (Clave Única de Identificación Tributaria). Authentication produces a temporary token and sign that authorize subsequent requests.
Invoice data submission. The issuer sends the invoice data in XML format to ARCA's electronic invoicing web service, known as WSFE (Web Service de Facturación Electrónica) or its current version WSFEv1. The XML payload includes the invoice type, point of sale number, recipient's CUIT, taxable amounts, VAT breakdowns, and any applicable perceptions or withholdings.
Validation and response. ARCA validates the submitted data against multiple criteria: sequential numbering for the point of sale, correct tax categorization of both parties, mathematical consistency of amounts and tax calculations, and the issuer's authorization to emit that invoice type. If validation passes, ARCA returns the CAE and its expiration date. If it fails, the response includes error codes identifying which fields or rules were violated.
Invoice completion. The issuer incorporates the CAE and its expiration date into the final invoice document before delivering it to the recipient. An invoice transmitted to a customer without a valid CAE is not a legal fiscal document.

XML Format Requirements

Invoice data submitted to WSFEv1 must conform to ARCA's published XML schema. Key structural elements include the FECAESolicitar method call, which wraps the header data (point of sale, invoice type, quantity of records) and one or more detail records containing the commercial and tax data for each invoice. Amounts are expressed as integers representing the value multiplied by 100, avoiding floating-point precision issues. Date fields follow the YYYYMMDD format without separators.

Error handling requires parsing the response XML for both the Resultado field (indicating approval or rejection) and any Observaciones or Errors nodes that provide specific rejection codes. Common rejection causes include duplicate invoice numbers, mismatched tax categories between issuer and recipient, and amounts that fail internal consistency checks.

QR Code Requirements

Since December 2020, all electronic invoices must include a QR code that encodes verification data in a standardized format. The QR contains a URL pointing to ARCA's verification service, with parameters that include the invoice version, date of issue, CUIT of the issuer, point of sale number, invoice type and number, the total amount, currency, recipient's CUIT, the CAE, and its expiration date. This allows any recipient or auditor to scan the code and verify the invoice's authenticity directly against ARCA's records.

The data encoded in the QR is Base64-encoded JSON appended as a query parameter to the verification URL. Generating this correctly requires attention to the exact field names and data types specified in ARCA's technical documentation.

ARCA maintains separate homologación (testing) and production environments for web service integration. Each requires its own authentication certificate, and CAE codes issued in testing have no legal effect.

CAEA: The Anticipated Authorization Code and Its 2026 Transition

The CAEA (Código de Autorización Electrónico Anticipado) is a batch authorization mechanism that operates on a fundamentally different model than real-time CAE clearance. Rather than submitting each invoice individually for approval, taxpayers request a block of authorization codes covering a half-month period, either the 1st through the 15th or the 16th through the end of the month. Once obtained, these codes are assigned to invoices locally without any real-time web service call to ARCA at the moment of issuance.

This model was designed for high-volume operations where constant connectivity to ARCA's servers was impractical or unreliable. Logistics companies issuing thousands of freight invoices daily, fuel distributors processing transactions at remote stations, and large retail chains generating high volumes of receipts across distributed locations all gravitated toward CAEA. The mechanism gave these businesses the flexibility to continue issuing valid electronic invoices even when network conditions or transaction speed requirements made real-time authorization unfeasible.

General Resolution 5785 changes this arrangement significantly. Starting in June 2026, CAEA will be restricted to emergency contingency use only. It will no longer function as a primary authorization method for routine invoicing. All taxpayers, including those currently operating under CAEA for day-to-day billing, must transition to real-time CAE authorization as their standard process.

The practical impact falls hardest on businesses that built their invoicing infrastructure around the batch model. Systems designed to request codes in advance and assign them offline will need to be re-architected to support real-time web service calls for every invoice — ensuring reliable connectivity to ARCA's servers, handling synchronous responses including rejections, and building fallback procedures for the now-contingency-only CAEA path.

Mandatory Invoice Fields After April 2025

Argentina's tax authority now requires a uniform set of data elements on every electronic invoice, regardless of taxpayer size. Following two regulatory changes in quick succession, the mandatory field list expanded significantly, and practitioners should audit their invoicing systems against the complete requirements below.

Issuer Information

Every electronic invoice must identify the issuer with the following fields:

CUIT (Clave Única de Identificación Tributaria), the 11-digit tax identification number
Ingresos Brutos registration number, reflecting the issuer's provincial gross income tax enrollment
VAT registration status (Responsable Inscripto, Monotributista, Exento, etc.)
Legal business name (razón social) or registered trade name
Registered commercial address (domicilio comercial)

Recipient Information

CUIT for business-to-business transactions
DNI (Documento Nacional de Identidad) for sales to final consumers, where applicable
Recipient name or business name

Invoice Identifiers

Date of issue (fecha de emisión)
Sequential invoice number, which must follow an unbroken numeric sequence per point of sale and invoice type
Point-of-sale code (punto de venta), the four- or five-digit number assigned to each billing location or electronic billing system
Invoice type letter (A, B, C, M, T, or E), determining the tax treatment and permitted issuer-recipient combination

Line Item Detail

Description of the goods or services
Quantity
Unit price
Net amount per line item

Tax Totals and Breakdown

This is where the April 2025 changes hit hardest. Prior to 2025, many invoices carried a single lump-sum total without granular tax detail. General Resolution 5614, effective January 2025, required large companies (those exceeding specific revenue thresholds) to itemize VAT amounts at each applicable rate and to separately disclose other indirect taxes on every invoice.

General Resolution 5616 then extended these requirements to all taxpayers starting April 2025. The mandatory tax fields now include:

VAT amounts broken out by each applicable rate (21%, 10.5%, 27%, or exempt)
Other national, provincial, or municipal indirect taxes, each itemized separately
Currency code and exchange rate for any transaction denominated in foreign currency, also mandated under GR 5616 for invoice types A, B, C, and E

The phasing matters for compliance audits: if an organization was below the GR 5614 threshold and did not update its invoice templates until April 2025, any invoices issued between January and March 2025 without itemized tax detail were still compliant. From April 2025 onward, no taxpayer is exempt from these itemization requirements. Countries across the region are tightening similar rules. For comparison, Brazil's ICMS state tax rules on invoices impose their own detailed tax field mandates on every nota fiscal.

Authorization and Verification

CAE code, the unique authorization number returned by ARCA upon real-time clearance
CAE expiration date, after which the invoice is no longer valid for tax purposes
QR code encoding verification data, allowing recipients and auditors to validate the invoice directly against ARCA's records by scanning the code

Digital Retention Requirement

Electronic invoices must be stored in their original digital format for a minimum of 10 years from the date of issue. This obligation applies to both issuers and recipients. The retention period covers the statute of limitations for tax audits and extends beyond it as a safeguard, so practitioners should ensure their archival systems meet this timeline before assuming older records can be purged.

Libro IVA Digital: The Closed-Loop Tax Reporting System

The Libro IVA Digital, or Digital VAT Ledger, is a mandatory monthly submission that records all fiscal debits and credits with ARCA. Every sales invoice issued and every purchase invoice received must appear in this ledger. Approximately 90% of Argentine taxpayers are required to submit it, making the Libro IVA Digital the connective tissue between e-invoicing and tax compliance for the vast majority of businesses operating in the country.

What makes the Argentine system distinctive is its closed-loop architecture. When a taxpayer issues an invoice and receives a CAE authorization, that transaction data enters ARCA's systems in real time. The same data then flows into the Libro IVA Digital as a fiscal debit. Purchase invoices received from suppliers, also CAE-authorized, appear as fiscal credits. The Libro IVA Digital aggregates these debits and credits monthly, and that aggregation feeds directly into VAT return calculations. The result is an end-to-end digital chain that runs from individual transaction through to tax filing, with no manual transcription steps required between stages.

This closed-loop model resembles what other Latin American countries are building toward. Brazil's NF-e electronic invoice system follows a similar philosophy of capturing tax-relevant data at the point of issuance, though Argentina's integration between invoice authorization and VAT returns is among the most tightly coupled implementations in the region. Uruguay provides a useful nearby contrast because its DGI-managed CFE framework pairs mandated electronic documents with explicit fallback rules, which the guide to Uruguay's CFE requirements and contingency handling explains in practical terms.

IVA Simple and Pre-Filled VAT Returns

Starting in November 2025, ARCA introduced IVA Simple through Form F.2051, a pre-filled VAT return generated from Libro IVA Digital data. Rather than building VAT declarations from scratch, taxpayers receive a return that already reflects their invoiced sales and documented purchases. The obligation shifts from preparation to review: verify the pre-filled figures, make corrections where necessary, and confirm.

The July 2026 milestone pushes this further. VAT declarations will be auto-populated directly from e-invoice data held in the Libro IVA Digital, reducing the taxpayer's role to reviewing and confirming the return rather than assembling it. This effectively closes the last gap in the digital chain between invoice issuance and tax filing.

2025-2026 Regulatory Timeline

Argentina's e-invoicing framework is undergoing rapid change across 2025 and 2026. The following timeline consolidates every major regulatory milestone into a single reference, with the General Resolution or Decree behind each change and the practical steps practitioners need to take.

January 2025: Itemized Tax Disclosure for Large Companies General Resolution 5614/2024 requires large taxpayers (grandes contribuyentes) to itemize VAT, internal taxes, and other indirect taxes as separate line items on all invoices, rather than embedding taxes in unit prices.

April 2025: Universal Tax Itemization and Exchange Rate Fields General Resolution 5616/2024 extends the itemization requirement to all taxpayers regardless of size. The same resolution mandates that Type A, B, C, and E invoices include the applicable exchange rate when the transaction involves foreign currency.

November 2025: IVA Simple (Form F.2051) Becomes Mandatory Pre-filled VAT returns through IVA Simple become mandatory for all applicable taxpayers via Form F.2051. The form draws directly from Libro IVA Digital data, meaning discrepancies between filed invoices and declared VAT become immediately visible to ARCA.

December 2025: Type M Invoices Eliminated General Resolution 5762/2025 retires Type M invoices entirely, replacing them with standard Type A invoices. Billing systems must remove Type M as a document class and remap any automated logic that triggered Type M issuance.

June 2026: CAEA Restricted to Emergency Contingency Use General Resolution 5785 restricts CAEA to emergency contingency situations only. Businesses using CAEA for routine invoicing must migrate to real-time CAE authorization. Point-of-sale and invoicing platforms must support synchronous web service calls to ARCA for every invoice, with CAEA available only as a connectivity fallback.

July 2026: Financial Sector E-Invoicing and Auto-Populated VAT Declarations E-invoicing becomes mandatory for financial institutions (banks, insurance companies). Simultaneously, ARCA will generate auto-populated VAT declarations derived directly from e-invoice data across the economy — corrections must be made at the invoice level before the declaration period closes.

This timeline reflects published resolutions as of early 2026. ARCA continues to issue regulatory updates, and practitioners should monitor the official gazette and ARCA's resolution feed for additional changes that may affect intermediate deadlines or technical specifications.