Argentina Electronic Invoicing: A Guide to Factura Electrónica

Guide to Argentina's factura electrónica: invoice types A-E, CAE authorization, mandatory fields, Libro IVA Digital, and 2025-2026 regulatory changes.

Published
Updated
Reading Time
21 min
Topics:
Tax & ComplianceArgentinae-invoicingfactura electrónicaclearance modelARCACAE authorization

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, and the technical specifications, web services, and taxpayer obligations carried over without interruption. If you've worked with AFIP's e-invoicing systems before, the mechanics are the same — the institutional name and oversight structure changed, but the plumbing did not.

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.

For practitioners navigating Argentina electronic invoicing requirements for the first time, the critical takeaway is that this is a tightly coupled system. The invoice type you issue, the authorization code you receive, the QR code you print, and the VAT ledger entry that ARCA generates are all interdependent. Getting one element wrong cascades into compliance problems across the others.


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 StatusRecipient StatusInvoice TypeVAT Treatment
Responsable InscriptoResponsable InscriptoAVAT itemized separately on the invoice
Responsable InscriptoFinal consumer or VAT-exempt entityBVAT included in the total price (not broken out)
Responsable Inscripto (under fiscal monitoring)Responsable InscriptoMVAT itemized; mandatory withholding legend applied
MonotributistaAny recipientCNo VAT itemization permitted
Hotels / tourism operatorsForeign touristsTVAT refund mechanism for eligible purchases
Any taxpayerForeign buyer (export)EZero-rated VAT (export invoice)

What Each Type Means in Practice

Type A is the standard business-to-business invoice between two VAT-registered entities. The recipient uses the itemized VAT as an input credit against their own VAT liability. Getting the Type A designation wrong, or issuing a Type B when a Type A is required, directly affects the recipient's ability to claim that credit.

Type B applies when the recipient has no use for a VAT credit, either because they are a final consumer or because they hold a VAT-exempt status. The tax is embedded in the price rather than displayed as a separate line item.

Type C reflects the Monotributo regime's core simplification. Because Monotributistas pay a flat fee that covers their VAT obligation, they cannot break out VAT on their invoices. A Type C invoice goes to every recipient regardless of that recipient's own tax status.

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.

The invoice type designation also determines which fields ARCA requires at the moment of authorization and whether withholding percentages must be calculated. Mismatched invoice types between buyer and seller records trigger automated cross-referencing alerts in the Libro IVA Digital reporting system, so selecting the wrong letter is not just a formatting error — it is a compliance failure that can generate fiscal penalties and delay VAT credit recovery.


If you compare Latin American invoice controls across countries, Peru's detraccion invoice rules and SPOT operation codes show a different model again, where part of the transaction is redirected into a mandatory deposit workflow instead of being handled through Argentina's invoice-letter logic. Chile's boleta electronica delivery requirements for in-person sales highlight a different control point again, where compliance turns on how the customer copy is delivered at the point of sale rather than on pre-clearance of the invoice itself. Colombia adds another variation when the buyer must prepare a documento soporte for purchases from suppliers who are not obligated to invoice instead of relying on a supplier-issued fiscal invoice.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Production and Testing Environments

ARCA maintains two separate environments for web service integration. The homologación (testing) environment allows developers and ERP vendors to validate their integration without generating real fiscal documents. CAE codes issued in the testing environment have no legal effect and use a distinct endpoint URL. Once testing confirms that requests and responses are handled correctly, the integration switches to the production environment endpoint, where issued CAEs are legally binding.

Both environments require their own authentication certificates. A certificate generated for testing will not authenticate against production, and vice versa. This separation ensures that development activity never accidentally creates valid fiscal obligations.


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. This means ensuring reliable connectivity to ARCA's servers, handling synchronous responses including rejections, and building fallback procedures for the now-contingency-only CAEA path. Organizations still relying on CAEA for routine operations should begin planning their migration well before the June 2026 deadline, as both system upgrades and internal process changes require lead time to test and deploy reliably.


From AFIP to ARCA: What the Restructuring Means for E-Invoicing

In October 2024, Argentina dissolved its longstanding tax authority AFIP (Administración Federal de Ingresos Públicos) through Decree 953/2024 and replaced it with a new agency: ARCA (Agencia de Recaudación y Control Aduanero). The stated rationale was to reduce bureaucratic overhead and streamline tax administration, with projected annual savings of 6.4 billion pesos through staff reductions and organizational consolidation.

For e-invoicing practitioners, the natural question is whether this restructuring altered the technical or procedural requirements they rely on daily. The short answer: it did not. Existing e-invoicing infrastructure, including web service endpoints, the CAE authorization process, invoice type classifications, and digital certificate workflows, carried over to ARCA with substantive continuity. What changed was the governing authority's name, branding, and internal organizational structure. Web service URLs and certificate processes transitioned to reflect ARCA branding, but the underlying protocols and data schemas remained intact.

The broader trajectory of Argentine tax modernization reinforces this continuity. According to the World Bank's 2025 announcement of a US$300 million tax modernization project for Argentina, the project aims to enhance tax administration efficiency, effectiveness, and transparency through ARCA by simplifying procedures, automating administrative processes, and advancing pre-filled digital tax forms that reduce the administrative burden on taxpayers. This signals that ARCA is not merely a renamed AFIP but an institution positioned to receive sustained investment in digital tax infrastructure.

Practitioners and foreign advisors should be aware that a significant volume of legacy documentation, technical guides, and community resources still reference AFIP. Official resolutions issued before October 2024, web service integration guides, and third-party compliance tools may all use the former name. When encountering these references, treat ARCA as the current and sole authority for all e-invoicing matters. The legal continuity established by Decree 953/2024 means that prior AFIP resolutions governing electronic invoicing remain in force unless explicitly superseded by new ARCA resolutions.


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.

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.

Why Invoice-Level Accuracy Matters More Than Ever

The practical consequence of this architecture is straightforward but critical: because e-invoice data directly populates tax returns, every error at the invoice level cascades into the VAT filing. A misclassified IVA rate, an incorrect CUIT, or a wrong invoice type code does not stay contained in a single document. It propagates through the Libro IVA Digital and surfaces in the pre-filled VAT return. Correcting errors after the fact means amending both the invoice record and the affected tax filing, a process that adds administrative burden and can trigger ARCA scrutiny. Getting invoices right at the point of issuance is no longer just good practice. Under the closed-loop system, it is the most efficient form of tax compliance.


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. Companies in this category must update their billing systems to break out each tax component individually rather than embedding taxes in unit prices. ERP tax configuration tables and invoice templates need modification before the enforcement date.

April 2025: Universal Tax Itemization and Exchange Rate Fields General Resolution 5616/2024 extends the itemization requirement from January to all taxpayers, regardless of size. Every invoice issued from April onward must display VAT and indirect taxes as discrete fields. The same resolution mandates that Type A, B, C, and E invoices include the applicable exchange rate when the transaction involves foreign currency. Practitioners need to confirm their invoicing software populates the exchange rate field automatically from ARCA's published rates, and that tax breakdowns appear on all document types. Client advisory notices should go out well before April, particularly to small and medium taxpayers who may not have tracked the January large-company rollout.

November 2025: IVA Simple (Form F.2051) Becomes Mandatory Pre-filled VAT returns through the IVA Simple regime become mandatory for all applicable taxpayers via Form F.2051. This form draws directly from data already submitted through Libro IVA Digital, meaning the tax authority auto-populates purchase and sales VAT figures from the e-invoice record. The practical impact is significant: discrepancies between filed invoices and declared VAT become immediately visible to ARCA. Accountants must reconcile Libro IVA Digital entries continuously throughout each tax period rather than adjusting figures at filing time. Any invoices with incorrect tax treatment or missing data will surface as mismatches in the pre-filled return.

December 2025: Type M Invoices Eliminated General Resolution 5762/2025 retires Type M invoices entirely, replacing them with standard Type A invoices. Taxpayers previously subject to the withholding and perception regime tied to Type M documents will now issue Type A invoices under revised conditions. Billing systems must remove Type M as a document class and remap any automated logic that triggered Type M issuance. Accountants managing clients who were assigned to Type M should verify their updated fiscal status in ARCA's registry and adjust withholding configurations accordingly.

June 2026: CAEA Restricted to Emergency Contingency Use General Resolution 5785 restricts the Anticipated Electronic Authorization Code (CAEA) to emergency contingency situations only. Businesses that currently use CAEA for routine invoicing must migrate entirely to real-time CAE authorization before June. This affects retailers, gas stations, and high-volume issuers who relied on CAEA's batch-style pre-authorization. System architecture changes are required: point-of-sale and invoicing platforms must support synchronous web service calls to ARCA for every invoice, with CAEA available only as a fallback when connectivity fails. Load testing and failover planning should be completed well ahead of the deadline.

July 2026: Financial Sector E-Invoicing and Auto-Populated VAT Declarations Starting July 2026, e-invoicing becomes mandatory for financial institutions, bringing banks and insurance companies fully into the electronic regime. Simultaneously, ARCA will begin generating auto-populated VAT declarations derived directly from e-invoice data submitted across the economy. Finance teams in newly covered institutions need full e-invoicing infrastructure operational by this date. For all taxpayers, the auto-populated declarations mean that ARCA's records effectively become the primary VAT ledger. Any 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.

About the author

DH

David Harding

Founder, Invoice Data Extraction

David Harding is the founder of Invoice Data Extraction and a software developer with experience building finance-related systems. He oversees the product and the site's editorial process, with a focus on practical invoice workflows, document automation, and software-specific processing guidance.

Editorial process

This page is reviewed as part of Invoice Data Extraction's editorial process.

If this page discusses tax, legal, or regulatory requirements, treat it as general information only and confirm current requirements with official guidance before acting. The updated date shown above is the latest editorial review date for this page.

Continue Reading

Invoice Data Extraction

Extract data from invoices and financial documents to structured spreadsheets. 50 free pages every month — no credit card required.

Try It Free