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 Original Invoice Conditions That Trigger REP

The key point is that REP does not arise merely because cash arrived after the invoice date. It arises from how the original Factura Electronica was issued. In practice, you start with the original invoice, check the sale condition recorded on that document, and only then decide whether a later payment event belongs in the REP workflow.

For the Article 27 credit scenario, the qualifying condition is sale-condition code 10: Venta a credito en IVA hasta 90 dias (Articulo 27, LIVA). That label matters because it ties the transaction to the specific VAT credit treatment described in Article 27 of the LIVA. In other words, the later payment receipt logic is anchored to a particular invoicing condition at issuance, not to generic accounts receivable activity.

That is why the sequence should be read plainly:

• First, a Factura Electronica is issued under the relevant original condition, especially code 10 where the transaction falls within the Article 27 framework.
• Later, a payment is received against that invoice.
• Only then do you assess whether that payment event must be documented through an REP.

Those are three different questions, and they are often blurred together:

• 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 the qualifying condition described in the official 4.4 materials.

For professionals reviewing a Costa Rica Article 27 LIVA payment receipt question, the safest approach is to test the original invoice first. If the original Factura Electronica does not carry the relevant condition, do not assume REP applies simply because the receivable remained open for days or weeks. The trigger is the original invoice setup, and code 10 is the core indicator for the Article 27 credit-sale workflow.

How Code 10 and Code 11 Work Together in the Payment Workflow

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 that invoice.

A practical workflow usually looks like this:

1. The supplier issues the original invoice.
2. That invoice shows the qualifying sale condition, especially the code 10 setup described in the Article 27 credit-sale workflow.
3. The customer pays after issuance, not at the same moment the invoice was created.
4. The business evaluates the payment event and, where REP treatment is required, issues the code 11 document to connect the receipt of funds back to the original code 10 invoice.

For finance and tax teams, the important control point is the gap between steps 2 and 4. During that period, 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. That means 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. Each later payment event still has to stay linked back to that same source invoice.

That invoice-to-payment structure will be familiar to teams that also work with other Latin American e-invoicing models. For example, Mexico's invoice-to-payment receipt workflow also separates the original invoice from the later payment record. The useful comparison is conceptual only: the pattern is regionally familiar, but Costa Rica's trigger conditions for REP depend on Costa Rican rules, not on another country's payment complement model.

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 Costa Rica original invoice key REP control. If the source document is electronic, preserve the full 50-digit clave numerica, not only an internal invoice number.
• 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.

The compliance purpose is straightforward: 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.

Partial-payment situations need tighter control over references and timing than a simple invoice-paid-in-full case. The same is true where public-sector acceptance, delayed treasury processing, or staged disbursements affect when payment is actually received.

That is why 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, do not rely on assumptions. Verify how the payment event should be captured, referenced, and sequenced in your ERP, e-invoicing setup, and adviser guidance.

A practical control standard is to ask three questions for each collection event:

1. Is this payment tied to an original invoice whose conditions already place it in a workflow that may require REP?
2. Can the payment amount be matched cleanly to that invoice, including any remaining unpaid balance?
3. Do our local advisers and system configuration support the way we plan to document this event?

That approach keeps the analysis anchored to official materials without stretching them. It also helps separate two issues that are often confused: whether the commercial transaction was invoiced correctly at the start, and whether later payment events, including those involving services provided to the State, are being documented with the reference discipline that REP workflows require.

Practical Checks Before You Issue or Expect an REP

Use this review sequence when testing Costa Rica REP requirements in procedures, ERP rules, and staff guidance:

1. Confirm the original invoice belongs to a qualifying workflow. If the source invoice was issued under the Article 27 credit-sale scenario tied to code 10, or you are dealing with a services-to-the-State situation flagged in 2025 guidance, the payment workflow deserves REP review.

2. Confirm the payment event is the trigger. REP belongs to the later payment step, including partial collections where applicable. Do not treat it as a general correction or status document.

3. Confirm the original invoice numeric key and reference data are available before processing. The payment document must stay tied to the exact source invoice. If the original invoice numeric key, reference relationship, issuance details, or payment allocation are missing or inconsistent, the REP workflow is not ready for controlled issuance.

4. Confirm staff understand the code sequence as part of the document model. In practice, REP should be reviewed as one element in Costa Rica's broader version 4.4 structure, not as an isolated code-entry task. This is where Costa Rica's broader e-invoicing and version 4.4 requirements matter for implementation, training, and validation.

5. Confirm special scenarios receive separate review. Services provided to the State, staged payments, and mixed operational handoffs between billing and treasury deserve explicit control points. These cases are more likely to fail if teams rely on informal notes instead of documented invoice-to-payment matching.

6. Confirm multi-country teams are not reusing the wrong logic. Costa Rica REP requirements are jurisdiction-specific. Other Latin American workflows may use different downstream documents, acceptance events, or VAT control points. For example, Chile's invoice acceptance and VAT-credit confirmation process serves a different function and should not be treated as the same trigger model.

7. Confirm the records you retain can support audit and reconciliation. At a minimum, keep the original invoice record, the original invoice numeric key, payment evidence, allocation details for any partial payment, and the final REP references aligned across accounting, tax, and operational systems.