# Cuaderno 60

Accept Spanish public-administration payments — municipal taxes, fees, multas, autoliquidaciones — using the AEB **Cuaderno 60 (60012)** standard. Citizens enter the Emisora, Referencia, and Identificación printed on their notice, MONEI validates the control digits client-side per Anexo común I, and the resulting payment carries flat metadata keys that your back office can use for reconciliation — and that MONEI assembles into the AEB **fichero** your collaborating bank expects.

This integration is no-code: configure a **C60 Point of Sale** in the Dashboard, share the link or QR, and citizens complete payment on the MONEI-hosted page.

## Overview[​](#overview "Direct link to Overview")

Cuaderno 60 is the AEB standard governing payment-collection for Spanish public administrations. Three modalities are supported:

| Modality  | Identificación length | Use case                                                                |
| --------- | --------------------- | ----------------------------------------------------------------------- |
| **Mod 1** | 7 digits              | Tributo + Ejercicio + Remesa (recurring tax remittances)                |
| **Mod 2** | 10 digits             | Periodic taxes with discriminante, año vencimiento, fecha juliana       |
| **Mod 3** | 13 digits             | Autoliquidación (model + sequence + DC) + NIF + optional fields per `Y` |

A single C60 Point of Sale supports all three. The customer-facing form length-detects the modality from the Identificación they type — no modality picker, no banner. Only digits can be entered; length and control-digit checks run when the citizen submits the form.

## Before You Begin[​](#before-you-begin "Direct link to Before You Begin")

* You'll need a MONEI account. Find your API keys in [MONEI Dashboard → Settings → API](https://dashboard.monei.com/settings/api).
* The C60 POS type is enabled for public-administration accounts. Contact [support](mailto:support@monei.com) if you don't see it.
* Use [test mode keys](https://docs.monei.com/testing/.md) for integration testing.
* Have your **Emisora** (6 digits with control digit) and the list of modalities you accept ready. Your organism's legal name and NIF come from your MONEI account's business profile — keep those up to date in Settings before creating the POS.

## 1. Create a C60 Point of Sale[​](#1-create-a-c60-point-of-sale "Direct link to 1. Create a C60 Point of Sale")

1. Go to [Dashboard → Settings → Points of Sale](https://dashboard.monei.com/settings/points-of-sale).
2. Click **Create Point of Sale**.
3. Select **Cuaderno 60** as the type.
4. Fill in the configuration:

| Field                         | Description                                                                                                                                                                                                          |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**                      | Identifier for this POS (e.g., "Recaudación municipal 2026")                                                                                                                                                         |
| **Emisora**                   | 6-digit Emisora code including control digit. Module-11 control digit validated when you save                                                                                                                        |
| **Allowed Modalities**        | Multi-select: **Mod 1**, **Mod 2**, **Mod 3**. Only checked modalities are accepted at the form                                                                                                                      |
| **Callback URL** *(optional)* | A web address MONEI calls automatically when a payment finishes, so your own systems are notified — a webhook. Leave it empty if you don't run a system to receive it; every payment still appears in the Dashboard. |
| **Description**               | Description passed to all payments from this POS                                                                                                                                                                     |

The organism's legal name and NIF on the receipt come from your account's business profile (Settings → Business), not from per-POS fields.

Save. The POS now has its own hosted **Cuaderno 60 payment page**. Distribute it however suits your service:

* **QR code** — download the POS [QR code](https://docs.monei.com/integrations/use-qr-payments/.md) as **SVG or PNG** (choose the size; it carries your branding colors and icon) and print it on notices, posters, or your sede electrónica. Scanning it opens the payment page.
* **Payment link** — share the page URL by email or SMS, or link it from your website.
* **Custom short link** — shorten the URL to a `monei.me` link and give it a memorable short name (lowercase letters, numbers, hyphens, and underscores), e.g. `monei.me/your-organization` — ideal for print and signage. Leave the name blank and MONEI generates one.

Every QR and link points at the same C60 Point of Sale, so all payments collected through them share its Emisora and configuration.

### Pre-filled links (deep-link to review)[​](#pre-filled-links-deep-link-to-review "Direct link to Pre-filled links (deep-link to review)")

To send a citizen straight to a specific bill, add the notice's data to the POS payment link as query parameters. MONEI fills the form on page load and, when the link supplies everything needed to pay, opens directly on the **review** screen — the citizen just confirms and pays. Encode that URL in a per-notice QR code for true one-tap payment.

**From the barcode.** Append the notice's full barcode sequence — the digits printed beneath the **código de barras** — as `c60Barcode`:

```
https://secure.monei.com/codes/68R5R843?c60Barcode=905224601380000136179980500126625700063106627800066261
```

All five AEB barcode formats are read: `502` and `508` (Modalidad 1), `521` and `522` (Modalidad 2), and `523` (Modalidad 3). Modalidad 1 and 2 barcodes carry the whole bill, so those links reach review on their own. A **Modalidad 3** barcode carries only the Emisora and Nº de justificante — the standard has no field for the amount or the NIF — so that link fills those two and leaves the rest for the citizen, unless you also pass the parameters below.

**From individual fields.** If your system holds the printed fields separately, pass them directly. Every parameter is optional and can be combined with `c60Barcode`:

| Parameter           | Field                                       |
| ------------------- | ------------------------------------------- |
| `c60Referencia`     | Referencia (12 digits, Modalidad 1 and 2)   |
| `c60Identificacion` | Identificación / Nº de justificante         |
| `c60Importe`        | Importe, e.g. `125.00` or `125,00`          |
| `c60Nif`            | NIF (Modalidad 3)                           |
| `c60Expediente`     | Número de expediente (Modalidad 3, per `Y`) |
| `c60FechaDevengo`   | Fecha de devengo, `DDMMAAAA` (Modalidad 3)  |
| `c60DatoEspecifico` | Dato específico (Modalidad 3, per `Y`)      |

```
https://secure.monei.com/codes/68R5R843?c60Referencia=000000009919&c60Identificacion=1005266257&c60Importe=125.00
```

When both are present the barcode wins for the fields it carries and the parameters fill the rest — which is how a Modalidad 3 link becomes payable in one tap:

```
https://secure.monei.com/codes/68R5R843?c60Barcode=905234616969020000002735&c60Nif=12345678Z&c60Importe=125.00
```

A link that doesn't add up to a payable notice simply opens the form with whatever it did supply, so the citizen finishes the rest by hand. Link values are validated on submit exactly like typed input — and only to the same extent: a barcode for a different Emisora, or one for a modality this POS doesn't accept, falls back to manual entry with the relevant message, but a wrong `c60Importe` is only caught where the Referencia check digit is validated (single-period Modalidad 2 — see [Validation rules](#validation-rules)). For Modalidad 1, con-recargo Modalidad 2, and Modalidad 3, the Importe you put in a link is the amount the citizen will be charged, so generate links from the same data as the printed notice.

## 2. Customer flow[​](#2-customer-flow "Direct link to 2. Customer flow")

<!-- -->

1. Citizen opens the link (from a printed notice, QR, email, etc.).

2. **Step 1 — Entry form.** They enter everything from their paper notice on one screen:

   * **Importe** — the amount to pay (preprinted on the bill for Mod 1/2, self-computed for Mod 3).
   * **Emisora** — read-only, pre-filled from your POS config.
   * **Referencia** — 12 digits (Anexo común I block).
   * **Identificación** — 7, 10, or 13 digits depending on modality (length-detected).
   * For **Mod 3**, an additional **NIF** field (and optional **Fecha de devengo**, **Expediente**, **Dato específico** depending on the `Y` indicator).

   **Scan instead of typing.** On a phone, the citizen can tap **Scan bill** and point the camera at the **código de barras** on the notice. MONEI reads it, validates the control digits, and — because the barcode carries the Emisora, Referencia, Identificación, and Importe — skips straight to the review screen. Scanning needs camera permission; a bill for a different Emisora or a modality this POS doesn't accept is rejected and the citizen types the fields instead. (Modalidad 3 self-assessments aren't fully encoded in the barcode, so those are entered manually.)

   When they continue, MONEI validates the control digits client-side per Anexo común I. If anything is wrong, the form highlights the invalid fields and scrolls to the first one — nothing advances until every field passes.

3. **Step 2 — Review and pay.** A confirmation screen lists the Importe, Emisora, Referencia, and Identificación, plus a plain-language line naming the tribute and ejercicio for recognized Mod 1/Mod 2 codes. The citizen can **Edit details** to go back, or continue to payment.

4. **Step 3 — Payment.** The citizen completes payment on the MONEI-hosted page — by card (recommended) or Bizum. The Cuaderno 60 metadata is already attached to the payment at this point.

5. **Receipt.** A Cuaderno 60 "Justificante de pago" section is rendered above the standard receipt with all spec fields (Organismo, Modalidad, Referencia, Identificación split per modality, Importe, Canal de pago, Fecha).

Spanish field names

The form labels **Emisora**, **Referencia**, **Identificación**, and **Modalidad** stay in Spanish across all locales — they are proper-noun spec terms. Surrounding chrome is translated normally.

## 3. Receipt and justificante de pago[​](#3-receipt-and-justificante-de-pago "Direct link to 3. Receipt and justificante de pago")

Every successful Cuaderno 60 payment produces a **Justificante de pago** — the citizen's proof of payment, and yours. The same Cuaderno 60 details appear in three places:

* **On the confirmation page**, right after payment (step 5 above).
* **In the receipt email** sent to the payer.
* **As a PDF**, attached to that email and downloadable from the payment's receipt page.

The justificante is an **extension of MONEI's standard receipt** — the same layout, with the Cuaderno 60 fields added above the usual amount and order details. Payments that aren't Cuaderno 60 show the standard receipt unchanged. Spec field names (**Organismo**, **Modalidad**, **Referencia**, **Nº de justificante**, **Identificación**…) stay in Spanish in every language; the surrounding text is translated normally.

### What each version shows[​](#what-each-version-shows "Direct link to What each version shows")

* **Email** — the essentials: the **Organismo**, the **Modalidad**, and the identifier (the **Referencia** for Modalidad 1 and 2, the **Nº de justificante** for Modalidad 3).
* **PDF** — the full per-modality breakdown below.

### Fields by modality (PDF)[​](#fields-by-modality-pdf "Direct link to Fields by modality (PDF)")

| Modalidad       | Identifier             | Breakdown shown                                                            |
| --------------- | ---------------------- | -------------------------------------------------------------------------- |
| **Modalidad 1** | Referencia (12 digits) | Identificación → Tributo · Ejercicio · Remesa                              |
| **Modalidad 2** | Referencia (12 digits) | Identificación → Discriminante · Tributo · Ejercicio · Año · Fecha juliana |
| **Modalidad 3** | Nº de justificante     | Modelo · Indicador · Secuencial · DC                                       |

For **Modalidad 3** (autoliquidación) the PDF also lists the **NIF** and any optional fields captured at payment time — **Fecha de devengo**, **Nº de expediente**, **Dato específico** — each shown only when present.

Modalidad 3 has no Referencia

The AEB Modalidad 3 document defines no Referencia — the citizen's reference is the **Nº de justificante**. The justificante intentionally omits a Referencia for Modalidad 3 even though one is stored in the payment metadata.

## 4. Payment metadata[​](#4-payment-metadata "Direct link to 4. Payment metadata")

Every successful Cuaderno 60 payment carries flat dot-notation metadata keys. Your callback handler (and any back-office tooling) can read them directly from the [Payment object](https://docs.monei.com/apis/rest/schemas/payment/.md) `metadata` field.

**Common to all modalities:**

| Key              | Value                          |
| ---------------- | ------------------------------ |
| `c60_modalidad`  | `MOD_1` \| `MOD_2` \| `MOD_3`  |
| `c60_emisora`    | 6 digits (incl. control digit) |
| `c60_referencia` | 12 digits                      |

**Mod 1 — Tributo / Ejercicio / Remesa:**

| Key             | Value    |
| --------------- | -------- |
| `c60_tributo`   | 3 digits |
| `c60_ejercicio` | 2 digits |
| `c60_remesa`    | 2 digits |

**Mod 2 — Discriminante / Tributo / Ejercicio / Año / Fecha Juliana:**

| Key                         | Value             |
| --------------------------- | ----------------- |
| `c60_discriminante_periodo` | `1` \| `5` \| `9` |
| `c60_tributo`               | 3 digits          |
| `c60_ejercicio`             | 2 digits          |
| `c60_anyo_vencimiento`      | 1 digit           |
| `c60_fecha_juliana`         | 3 digits          |

Con-recargo bills

For a two-period bill (`c60_discriminante_periodo` `5` or `9`), every field above — including `c60_referencia` from the common set — reflects **whichever period was actually charged**, not always the first one. Reconcile against these fields directly rather than assuming the voluntary period.

**Mod 3 — Justificante (Modelo + Y + Secuencial + DC) + NIF + optionals:**

| Key                   | Value      | Notes                             |
| --------------------- | ---------- | --------------------------------- |
| `c60_modelo`          | 3 digits   | Modelo de autoliquidación         |
| `c60_y_indicator`     | `0`..`8`   | Gates which optional fields apply |
| `c60_secuencial`      | 8 digits   |                                   |
| `c60_dc`              | 1 digit    | Justificante control digit        |
| `c60_nif`             | 9 chars    | Omitted when `Y = 8`              |
| `c60_fecha_devengo`   | `DDMMAAAA` | Optional; gated by `Y`            |
| `c60_expediente`      | 12 chars   | Optional; gated by `Y`            |
| `c60_dato_especifico` | 20 chars   | Optional; gated by `Y`            |

The Y-indicator gating for Mod 3 follows Anexo común I:

| `Y` | Includes                                              |
| --- | ----------------------------------------------------- |
| `0` | NIF only                                              |
| `1` | NIF + Expediente                                      |
| `2` | NIF + Fecha de devengo                                |
| `3` | NIF + Expediente + Fecha de devengo                   |
| `4` | NIF + Dato específico                                 |
| `5` | NIF + Expediente + Dato específico                    |
| `6` | NIF + Fecha de devengo + Dato específico              |
| `7` | NIF + Expediente + Fecha de devengo + Dato específico |
| `8` | No NIF, no opcionales                                 |

**Reconstructed at receipt / export time (not stored):**

* **Canal de pago** = `4` ("Pasarela de pagos") — hardcoded per spec.
* **Fecha de captura** = `payment.completedAt`.
* **Importe** = `payment.amount`.

Why split fields?

The flat split-field layout means your reconciliation script doesn't need to re-parse a composite Referencia/Identificación — every field is already in its canonical position. Composites are trivial to reassemble at render time when you need them.

## 5. Receive payment status (webhook)[​](#5-receive-payment-status-webhook "Direct link to 5. Receive payment status (webhook)")

MONEI sends the final, authoritative payment status via an asynchronous HTTP POST to your `callbackUrl`. The request body is the full [Payment object](https://docs.monei.com/apis/rest/schemas/payment/.md) in JSON — including all `metadata.c60_*` keys.

You must:

1. **Verify the MONEI-Signature header** — see the [Verify Signatures guide](https://docs.monei.com/guides/verify-signature/.md).
2. **Return `200 OK`** immediately. Any other status causes MONEI to retry.

Once verified, inspect `status` (`SUCCEEDED`, `FAILED`, `CANCELED`, ...) and persist the c60 metadata against your internal ledger.

## 6. Export a reconciliation fichero[​](#6-export-a-reconciliation-fichero "Direct link to 6. Export a reconciliation fichero")

At the end of each **quincena** (half-month — days 1–15, then 16 to month-end), MONEI assembles your collected Cuaderno 60 payments into the AEB **fichero**: the fixed-width file your collaborating bank expects for reconciliation. MONEI files it as the **entidad colaboradora** (N.R.B.E. `6911`), so you don't build the file yourself.

Each quincena produces one **fichero per Emisora**, split by modality into one or two files:

| File          | Contents                                            |
| ------------- | --------------------------------------------------- |
| **Anexo 1-1** | Modalidad 1 + Modalidad 2 payments (operación `70`) |
| **Anexo 2-1** | Modalidad 3 / autoliquidaciones (operación `80`)    |

Every payment's Referencia, Identificación, and Importe land in their canonical positions, with canal de pago `4` (Pasarela de pagos). The **Emisora** written into the file is the one frozen on each payment at collection time, so editing a POS Emisora later never rewrites already-collected payments.

There are two ways to get the fichero.

### On-demand download[​](#on-demand-download "Direct link to On-demand download")

1. Go to [Dashboard → Payments](https://dashboard.monei.com/payments) and click **Export**.
2. Choose **Cuaderno 60** as the export format. (For public-administration accounts it's the default.)
3. Pick the **C60 Point of Sale**, then the **year**, **month**, and **quincena** (1st or 2nd half).
4. Download — you get a `.zip` containing the one or two `.txt` files for that quincena.

### Scheduled SFTP delivery[​](#scheduled-sftp-delivery "Direct link to Scheduled SFTP delivery")

To have MONEI push the raw `.txt` files to your bank or back office automatically, add an [SFTP destination](https://docs.monei.com/manage-account/sftp-reports/.md) and choose **Cuaderno 60** as its export type. MONEI then delivers on the AEB filing days:

| Filing day | Quincena delivered                         |
| ---------- | ------------------------------------------ |
| **20th**   | Current month, 1st half (days 1–15)        |
| **5th**    | Previous month, 2nd half (16 to month-end) |

If a filing day falls on a weekend or holiday (festivo), delivery shifts to the next business day. SFTP sends each `.txt` individually — banks reject zipped ficheros.

Public-administration accounts

The Cuaderno 60 export format and SFTP type appear only for public-administration accounts. If you don't see them, [contact support](mailto:support@monei.com).

## Validation rules[​](#validation-rules "Direct link to Validation rules")

Before the payment is created, MONEI checks the entry form against Anexo común I:

* **Control digits** — the Emisora and (Modalidad 3) the Nº de justificante each carry a check digit that must match. The **Referencia** check digit is validated for single-period Modalidad 2 references (the common preprinted bill). Because that digit binds the Referencia, Identificación, and Importe together, a mismatch can't point at one field — the form shows a general "double-check the amount, reference, and identification" message instead of highlighting a single input. Modalidad 1 references are accepted as printed. A two-period (con recargo) Modalidad 2 bill prints a **separate** check digit for each period — MONEI already selects the matching Referencia, Identificación, and Importe together for whichever period applies (see the deadline rule below), but doesn't verify either period's digit yet, so a transcription error in a con-recargo Referencia isn't caught client-side.
* **Identificación structure** — the correct length and per-modality field shapes for the detected modality.
* **Allowed modalities** — if the citizen's modality isn't one you enabled on the POS, the form rejects it with `Esta entidad no acepta Modalidad X`.
* **Payment deadline (Modalidad 2)** — a Modalidad 2 bill encodes its own deadline (año de vencimiento + fecha juliana) in the Identificación. A **single-period** bill (discriminante `1`) is rejected outright once that date passes. A **two-period, con-recargo** bill (discriminante `5`/`9`) instead switches — once the voluntary deadline passes — to its surcharge Importe together with that period's own Referencia and Identificación, since each period is a distinct entry on the notice; it's rejected in turn once the surcharge period's own deadline (also encoded in the barcode) has passed. Paying on either deadline day itself still counts as on time. Modalidad 1 and 3 barcodes carry no deadline.

Validation runs when the citizen submits the form — there's no per-keystroke checking. On a failed submit, the form highlights every invalid field, jumps to the first, and stays on the entry step until they're all correct.

## Testing[​](#testing "Direct link to Testing")

* Use your [test mode API keys](https://docs.monei.com/testing/.md) for development.
* Enable Test Mode in your [Dashboard](https://dashboard.monei.com/payments) to view test payments.
* Use [test card numbers](https://docs.monei.com/testing/.md) to complete the card step.
* Verify webhook delivery in Dashboard → Developers → Webhooks.

## Limitations[​](#limitations "Direct link to Limitations")

* **Maximum €3,000.00 per payment** — the entry form rejects an Importe above €3,000.00.
* **Browser back / refresh / multi-tab** discards Cuaderno 60 form entries — the citizen must re-type. Customer-facing copy on the form acknowledges this.
* **Duplicate payments of the same notice are rejected.** Each Cuaderno 60 payment carries an order ID derived from the notice (Emisora + Referencia + Identificación; Modalidad 3 uses the Nº de justificante), and MONEI refuses a second payment for an order that is already authorized or paid. For a two-period, con-recargo Modalidad 2 bill this identifier is the same regardless of which period is actually paid, so a retry after the surcharge period has started is still recognized as the same notice. A failed attempt doesn't block a retry. The same identifier appears as the payment's `orderId` for your reconciliation.

## Troubleshooting[​](#troubleshooting "Direct link to Troubleshooting")

**"Longitud inválida" shown on Identificación field** Length must be exactly 7, 10, or 13 digits. Trim whitespace; Unicode digit variants are rejected.

**"Esta entidad no acepta Modalidad X"** The detected modality isn't in your POS `allowedModalities`. Either expand the whitelist in the Dashboard or instruct the citizen to use a different reference.

**"Dígito de control inválido"** The Modalidad 3 Justificante control digit doesn't match. Re-check the printed notice — most often a transcription typo on one of the digits.

**"Please double-check the amount, reference, and identification"** The Referencia check digit doesn't match the entered Referencia + Identificación + Importe combination (single-period Modalidad 2 only). Any of the three fields could carry the typo — compare all of them against the printed notice.

**"The order has already been paid" / "…has already been authorized"** The same notice already has a paid — or authorized but not yet captured — payment. Duplicates of one notice identifier (Emisora + Referencia + Identificación; Nº de justificante for Modalidad 3) are rejected. Look up the prior payment by `orderId` in the Dashboard.

**Bill rejected as expired** The Modalidad 2 bill's payment deadline — encoded in the Identificación — has already passed: the voluntary deadline for a single-period bill, or the surcharge period's own deadline for a two-period, con-recargo bill. This channel doesn't accept payment past that date; direct the citizen to your organism's usual out-of-term collection process (vía ejecutiva).

**Webhook not received** Verify your `callbackUrl` is publicly accessible, returns `200 OK`, and check webhook logs in Dashboard.