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 — 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
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 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
- You'll need a MONEI account. Find your in MONEI Dashboard → Settings → API.
- The C60 POS type is enabled for public-administration accounts. Contact support if you don't see it.
- Use test mode keys 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
- Go to Dashboard → Settings → Points of Sale.
- Click Create Point of Sale.
- Select Cuaderno 60 as the type.
- 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 . 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 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.melink 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)
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). 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
-
Citizen opens the link (from a printed notice, , email, etc.).
-
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
Yindicator).
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.
-
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.
-
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.
-
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).
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
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
- 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)
| 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.
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
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 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 |
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.
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)
MONEI sends the final, authoritative payment status via an asynchronous HTTP POST to your callbackUrl. The request body is the full Payment object in JSON — including all metadata.c60_* keys.
You must:
- Verify the header — see the Verify Signatures guide.
- Return
200 OKimmediately. 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
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
- Go to Dashboard → Payments and click Export.
- Choose Cuaderno 60 as the export format. (For public-administration accounts it's the default.)
- Pick the C60 Point of Sale, then the year, month, and quincena (1st or 2nd half).
- Download — you get a
.zipcontaining the one or two.txtfiles for that quincena.
Scheduled SFTP delivery
To have MONEI push the raw .txt files to your bank or back office automatically, add an SFTP destination 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.
The Cuaderno 60 export format and SFTP type appear only for public-administration accounts. If you don't see them, contact support.
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 (discriminante5/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
- Use your test mode API keys for development.
- Enable in your Dashboard to view test payments.
- Use test card numbers to complete the card step.
- Verify webhook delivery in Dashboard → Developers → Webhooks.
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
orderIdfor your reconciliation.
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.