Skip to main content
ARCA does not support cancellation. Once an invoice is authorized, it is a permanent fiscal record. When you need to correct or reverse an invoice — whether a full reversal, a partial refund, or a price adjustment — you issue a credit note. Credit notes are real fiscal documents that ARCA authorizes and records alongside the original. issueCreditNote() handles both partial corrections (specific lines) and total reversals (all: true), deriving the note type and fiscal structure from the original automatically.
Credit notes are permanent fiscal documents. Once ARCA authorizes a credit note, it cannot be undone. A test in production — even a note for ARS 0.01 — creates a real record in ARCA’s books. Both the original invoice and the note remain in ARCA’s records indefinitely.

Partial credit note

The most common case is a partial credit note: a refund or price correction that credits only the lines you specify, not the entire invoice.

Total credit note

Pass all: true to credit the entire original invoice. The SDK fetches the original and mirrors its amounts and VAT rates line by line — you don’t need to know the original breakdown.
The mode — items, amounts, or all: true — is explicit and required. An input that provides none of them, or that combines all: true with items or amounts, throws before any network I/O. A forgotten field can never silently credit the entire invoice.

The for field

object
required
Identifies the original voucher to credit. Takes { salesPoint, voucherType, number } — the three coordinates of the original authorized document. The SDK fetches the original from ARCA to derive the note type, fiscal class, recipient condition, currency, and VAT rates.
  • voucherType: 1 (class A invoice) → note type 3 (class A credit note)
  • voucherType: 6 (class B invoice) → note type 8 (class B credit note)
  • voucherType: 11 (class C invoice) → note type 13 (class C credit note)
Supported originals include ordinary (1, 2, 6, 7, 11, 12), retention-legend A (51, 52), and FCE (201, 202, 206, 207, 211, 212) invoices and debit notes.

What the SDK derives vs. what you provide

The SDK takes the following from the original:
  • Voucher class and therefore note type
  • Recipient VAT condition
  • Currency and exchange rate
  • Concept (products, services, or both) and service date range
You provide:
  • for — the original’s coordinates
  • The mode: items, amounts (with optional total), or all: true
  • Optionally: salesPoint for the note (defaults to the original’s sales point) and date (defaults to today in Buenos Aires)
A linked note never has issuer, to, or currency fields — those come from the original. Only period notes (which have no original) carry those fields.

Item shape follows the original’s class

The form of your items must match the fiscal class of the original:
  • Class C original → items are { amount } (integer centavos)
  • Class A or B original → items are { gross | net, vat } with the same VAT rates as issue()
If the item shape contradicts the class derived from the original, the SDK throws after fetching the original and before any authorization attempt.

Debit notes

issueDebitNote() issues a debit note against the same supported originals, using the identical contract. Debit notes do not accept all: true — because a debit note adds to the balance, its lines are always explicit.

Previewing notes

previewCreditNote() and previewDebitNote() derive the exact request that issuance would send. Unlike preview() for invoices, these methods are async because they need to fetch the original voucher from ARCA first (one read, no write, no number reservation).
A period note (one that uses associatedPeriod instead of for) has no original, so previewCreditNote() is synchronous in that case.

The amounts mode

Instead of line items, you can pass a pre-computed fiscal breakdown with amounts: { net, vat, exempt?, untaxed?, vatRates? } (all values in centavos). This is the correct choice when your application has already computed the breakdown and you want the SDK to send it as-is without recalculating VAT. An optional total asserts the expected total against the reconciliation rules. items and amounts are mutually exclusive, and neither combines with all: true.

Period notes

A period note adjusts a billing period rather than a specific invoice. Use associatedPeriod: { from, to } instead of for. Because there is no original to fetch, the note carries the same business fields as issue(): issuer, to, items or amounts, and optional currency.

FCE notes

A credit note against an FCE (Factura de Crédito Electrónica MiPyME) original requires an FCE original. Pass fce: { annulment, reference? } to explicitly declare whether this is an annulment — all: true does not infer it automatically.

Taxes on notes

A total credit note mirrors the original’s taxes as returned by the ARCA lookup. A partial credit note does not prorate anything: if the note needs to carry taxes, pass them explicitly in taxes using the same { id, description?, base, rate, amount } rows (all amounts in centavos) that issue() accepts. The SDK never infers which withholdings apply or in what proportion.

Limits and responsibility

The note cannot exceed the original’s total. The SDK does not track accumulated notes against an original — ensuring that multiple notes together do not exceed the original invoice is the responsibility of your application.