Costa Rica Recibo Electronico de Pago Requirements (REP)

Costa Rica Recibo Electronico de Pago requirements are narrower than many finance teams assume. In Costa Rica version 4.4, the Recibo Electronico de Pago (REP) is the document used to record payment of an original invoice issued under sale-condition code 10, and the REP itself uses code 11. It is not a generic receipt for every later payment. Costa Rica's official version 4.4 annex states that code 11, "Pago de venta a credito en IVA hasta 90 dias (Articulo 27, LIVA)," is used only for a Recibo Electronico de Pago that settles an original invoice issued with code 10.

That gives you a direct answer to when is REP required in Costa Rica:

• REP applies when a later payment settles an original invoice issued under the qualifying code 10 credit-sale condition.
• REP deserves explicit review when Hacienda's 2025 guidance flags a services-to-the-State workflow and the payment event still has to be tied back to the original invoice with the correct references.

This article is a workflow reference for accountants, AP teams, finance operations staff, and tax advisers. It translates the official Ministerio de Hacienda and Direccion General de Tributacion version 4.4 materials into plain English so you can decide whether the payment belongs inside the REP workflow and what records need to stay linked.

The Sale Condition That Triggers an REP

REP does not arise merely because cash arrived after the invoice date. It arises from how the original Factura Electronica was issued. The qualifying condition is sale-condition code 10: Venta a credito en IVA hasta 90 dias (Articulo 27, LIVA) — the label that ties the transaction to the specific VAT credit treatment described in Article 27 of the LIVA.

Three different questions are often confused:

• Was the sale invoiced on credit?
• Was payment received after the invoice was issued?
• Does that later payment require a Costa Rica credit sale payment receipt in the form of an REP?

The answer to the third question is not automatically yes just because the first two are true. A business can issue an invoice, wait for payment, and still be outside the REP use case if the original electronic invoice was not issued under code 10.

Code 10 and code 11 work as a sequence, not as alternatives. Code 10 sits on the original invoice. Code 11 sits on the later Recibo Electronico de Pago (REP) that records payment against it. The practical workflow:

1. The supplier issues the original invoice under code 10 (Article 27 credit sale).
2. The customer pays after issuance.
3. Where REP treatment is required, the business issues a code 11 REP that ties the receipt of funds back to the original code 10 invoice.

For finance and tax teams, the control point is the gap between steps 1 and 3. The business should be able to show when the invoice was issued, whether payment was actually received, and which exact invoice the payment belongs to — preserving invoice identifiers, customer records, payment evidence, and the ERP references needed for reconciliation. Partial payments follow the same logic: the original invoice does not change, and each later payment event has to stay linked back to that same source invoice.

For an Article 27 LIVA payment-receipt question, test the original invoice first. If it does not carry code 10, do not assume REP applies simply because the receivable remained open. Mexico's Complemento de Pago follows a similar invoice-to-payment pattern under different Mexican rules.

What Reference Data Must Appear on an REP

In Costa Rica, an REP is not complete unless it clearly identifies the document it is settling. Under version 4.4, the Informacion de Referencia block is mandatory for a Recibo Electronico de Pago because the REP must point back to the original Factura Electronica or other permitted source document. That reference is what makes the payment document auditable instead of a standalone receipt.

At a minimum, finance teams should preserve the source-document details that let the REP point back to the right invoice:

• The type of referenced document. In the usual REP workflow covered here, that is the original Factura Electronica being paid.
• The original invoice numeric key. This is the core control: preserve the full 50-digit clave numerica, not only an internal invoice number, when the source document is electronic.
• The issue date of the referenced document.
• The reference code and reason fields your e-invoicing setup uses to describe the relationship to the original invoice.

Traceability, reconciliation, and proof of linkage. A Costa Rica electronic payment receipt should let a reviewer move from payment event to original invoice without guesswork. The REP should show exactly which prior document is being settled, when that source document was issued, and why the reference relationship applies.

The most common control failures are operational, not conceptual:

• Losing the original clave numerica as data moves from billing to ERP, treasury, or the e-invoicing layer.
• Matching the REP to the wrong invoice because several open credit invoices exist for the same customer or amount.
• Carrying only an internal invoice ID and omitting the Hacienda key.
• Reusing a generic reference reason that does not describe the actual source-document relationship.
• Treating the REP as a standalone payment document detached from the underlying Factura Electronica record.

A sound process is to have the REP inherit the original document type, original invoice key, and source issue date directly from the validated invoice record, then require a final check that the reference relationship still matches the payment being reported.

When Partial Payments and Services Provided to the State Enter the Picture

Partial and staged collections are where REP workflows become operationally important. A single full settlement is usually straightforward: there is one payment event to connect back to the original credit invoice. Once payment is split across installments, retained amounts, progress milestones, or delayed public-sector disbursements, the main task is no longer just confirming that money was eventually paid. It is documenting each payment event in a way that preserves a clear relationship to the underlying invoice and its original commercial conditions.

In practice, finance teams should treat each received payment as its own reporting checkpoint within a credit-sale workflow. That means keeping the invoice reference, payment date, amount applied, and remaining balance aligned across the receivable ledger, bank support, and any REP-related process. The objective is not to create a new tax position for every installment. It is to ensure that each payment occurrence can be traced to the original invoice without breaking the audit trail.

This is where fast pattern-matching helps:

Scenario	Practical reading
Original invoice issued with code 10, then payment arrives later	REP is the payment document to evaluate, and the payment event has to stay tied to that original invoice.
Payment arrives late, but the original invoice was not issued under the qualifying code 10 workflow	Do not assume REP applies just because the receivable stayed open. Start with the original invoice conditions.
Partial payment or staged settlement against a qualifying invoice	Keep each payment event linked to the same original invoice, with amounts, dates, and remaining balance aligned across records.
Services provided to the State	Flag the invoice at issuance, retain acceptance or milestone evidence, and confirm with your provider or adviser how the payment event should be referenced before receipt processing.

Services provided to the State deserve more than a generic warning. Hacienda's 2025 guidance treats them as a workflow that finance teams should review explicitly. If your entity issues invoices on credit and later receives payment in a State-related scenario, verify how the payment event should be captured, referenced, and sequenced in your ERP, e-invoicing setup, and adviser guidance before the receipt is processed.

Practical Checks Before You Issue or Expect an REP

Three checks for procedures, ERP rules, and staff guidance:

1. Verify the original invoice carries code 10. The Article 27 credit-sale condition on the source invoice is what places the payment event in the REP workflow. Without it, do not assume REP applies.
2. Preserve the original 50-digit clave numerica and reference fields on the REP. The payment document must point back to the exact source invoice; an internal invoice ID alone is not enough.
3. Flag partial payments and services-to-the-State for explicit review. Staged settlements, retained amounts, and delayed public-sector disbursements require documented invoice-to-payment matching, not informal notes.

REP review fits inside Costa Rica's broader version 4.4 document model — see Costa Rica's broader e-invoicing and version 4.4 requirements. Other Costa Rican v4.4 documents that intersect with the same workflow include the Mensaje Receptor acceptance flow for the original invoice and the Factura Electronica de Compra for buyer-issued purchase invoices.