How to Extract Data from Spanish Delivery Notes (Albaranes)
Into Excel

A Spanish delivery note carries a legal weight no generic delivery note has — and fields no generic template recognizes.

In most of Europe, a delivery note is a shipping document. It lists what's in the box, the driver hands it over, and the receiving clerk checks it against the purchase order. Nobody’s lawyer ever looks at it. In Spain, the albarán (delivery note) occupies a different category. Under the Código de Comercio (Spanish Commercial Code, Royal Decree of 22 August 1885), the albarán serves as documentary proof of delivery — traditio — in a compraventa (sale of goods) contract. It is not a tax instrument. It does not carry IVA (VAT) amounts. But it is the document that legally confirms goods changed hands.

The albarán is the only shipping document in the European supply chain that is simultaneously a legal delivery receipt and a turnaround document — the supplier prints it, the goods ride with it, the receiver writes on it, and the signed copy returns to the supplier as proof. The Wikipedia entry on albarán defines it clearly: "un documento mercantil que acredita el traslado y la entrega de un pedido" — a commercial document that certifies the transport and delivery of an order. The receiving party must sign it to confirm correct receipt. That signature transforms the document from a simple packing list into a legal record.

This legal role creates structural differences between a Spanish albarán and a generic delivery note. An albarán from a Spanish supplier — whether it’s Mercadona’s logistics center near Valencia or an industrial distributor like RS Components España — typically carries fields a British despatch note or a German Lieferschein does not. The tax ID field appears in NIF format (Número de Identificación Fiscal): 8 digits plus one check letter for individuals, one letter plus 7 digits plus one check letter for companies. Both the supplier’s NIF and the buyer’s NIF appear on the document. The delivery note number follows supplier-specific internal numbering that has no cross-supplier standard. And critically — because the albarán predates the invoice in the commercial workflow — the delivery note number must later be matched against the factura (invoice) that references it, enabling three-way reconciliation with the purchase order.

Every albarán carries 10–14 fields that matter for warehouse receiving — and their exact field labels vary by supplier.

When a Spanish warehouse receives a shipment, the receiving clerk needs to extract data from the albarán and enter it into either the WMS (Warehouse Management System) for inventory posting or the ERP for purchase order reconciliation. In Spain, the software doing the receiving is likely SAP Business One, Sage 200 (or Sage Murano, widely adopted in Spanish SMEs), Microsoft Dynamics NAV / Business Central, or the Spanish-built Holded SaaS ERP. For warehouse-specific operations, Mecalux Easy WMS — a Spanish WMS from the Barcelona-based intralogistics group Mecalux — is common in mid-to-large warehouses. The WMS expects structured data. The albarán is anything but.

The fields a Spanish warehouse typically extracts from each albarán, and where each one feeds downstream:

The Spanish Plan General de Contabilidad (PGC) determines where this data lands. When goods are received against an albarán, the accounting entry debits Grupo 3 (Existencias — Inventory, typically cuenta 600 for merchandise purchases or cuenta 601 for raw materials) and credits cuenta 400 (Proveedores). The albarán number is the reference that links the physical receipt to the accounting entry — before the factura arrives. If the albarán number is entered incorrectly, the three-way match between PO, delivery note, and invoice breaks at the accounting level.

Spanish warehouses face the same format fragmentation as any receiving dock — but the Spanish regulatory vacuum makes it permanent.

There is no Spanish law that mandates a standard albarán format. The Código de Comercio describes the document's function but does not prescribe its layout. AECOC (Asociación de Fabricantes y Distribuidores), Spain's GS1 standards body with over 35,000 member companies, has developed an electronic delivery note standard through its AECOC EDI and AECOC TRANSP platforms. But EDI adoption in Spanish logistics follows the same pattern as elsewhere: large retailers like Mercadona, Carrefour Spain, and El Corte Inglés mandate it for their Tier 1 suppliers, while the mid-market — regional distributors, industrial suppliers, local manufacturers — continues to ship with paper albaranes printed from whatever ERP the supplier happens to use.

The result is the same visual chaos a receiving clerk at a German or French warehouse faces, with one additional complication: Spanish suppliers frequently use carbon-copy albarán books. The top copy stays with the buyer, the second goes to the driver, and the third remains in the supplier's book. By the time the buyer's copy reaches the data entry desk, it may be a second or third generation carbon sheet with progressively faded text. Combine that with the handwritten annotations the receiver added at the dock — quantity corrections, damage notes, a signature — and you have a single page carrying three layers of information at different legibility levels.

UNO Logística, Spain's main logistics trade association representing over 350 logistics operators and transport companies, identifies digitalization of document workflows as a core priority in its sector agenda. But the association also notes that the fragmentation of document formats across the supply chain — particularly between large retailers using EDI and mid-market suppliers using paper — remains a structural barrier. The Centro Español de Logística (CEL), Spain's largest logistics professional community since 1978, has published on the document standardization challenge in its supply chain digitalization working groups. The consensus: standardization will come to high-volume corridors first, but the long tail of mid-market suppliers will continue producing heterogeneous paper and PDF albaranes for years.

You don't need a template for every supplier. You define your columns once and let the AI find each field by what it means.

The standard approach to extracting Spanish albarán data — typing every field from every supplier's unique layout into an Excel spreadsheet — takes about 3 minutes per single-page albarán according to industry benchmarks. For a warehouse receiving 30 shipments a day, that's 90 minutes of pure data entry. The alternative that tools like template-based OCR offer is worse in the Spanish context because it requires building a separate extraction template for every supplier layout — and Spanish suppliers, unlike German or French ones where format standardization is more advanced, show extreme variability. An albarán from a Catalan industrial supplier and one from an Andalusian food distributor share almost no visual similarity, even though they carry the same legal function.

What works instead is Custom Column Extraction: a method where you type the field names you want — "Delivery Note Number," "PO Reference," "Supplier NIF," "Product Code," "Quantity Shipped," "Receiver Signature" — and the AI reads each document to locate those values by understanding what each field name means semantically, not by matching a fixed pixel position. The column names you enter become the headers of your output spreadsheet. One column definition works across every supplier because the AI reads the document like a person would — looking for the meaning of each field rather than its coordinates on the page.

Here is the workflow end to end, using a batch of albaranes from multiple Spanish suppliers:

Try it below with a sample albarán. The demo uses a preset — a pre-configured set of column names matching the standard delivery note / packing slip structure — so you can see extraction results immediately without typing column names. Click "Process" and the AI reads both the printed shipment data and any handwritten receiving annotations on the page.

An albarán is the only logistics document that leaves the warehouse printed and returns with handwritten data — your extraction has to read both.

No other document in the shipping envelope makes a round trip. The purchase order stays with the buyer. The invoice is generated after delivery. The bill of lading moves with the carrier but does not return to the supplier covered in annotations. The albarán is unique: the supplier prints it, the goods travel with it, the receiver writes on it — circling a damaged box, writing "solo 8 uds recibidas" (only 8 units received) next to a line that says 10, signing at the bottom — and the annotated copy goes back to the supplier as proof of delivery condition.

This round-trip nature creates a two-layer document problem that most extraction tools handle poorly. Template-based OCR tools read the printed layer: the supplier's fields, the quantities as-shipped, the reference numbers. The handwritten layer — corrections, condition notes, a signature — is either ignored as noise or mixed into the printed text stream, producing output where "10 unidades" and "8 uds" land in the same cell.

A semantic reader that understands field meaning, rather than matching pixel blocks, can separate the two layers into distinct columns. Define Qty Shipped and the AI reads the printed quantity from the supplier's line-item table. Define Qty Received in the same column setup and the AI reads the handwritten correction the receiver wrote next to it. Define Exception Notes and handwritten margin comments — "caja dañada" (damaged box), "embalaje roto" (broken packaging), "falta 2" (2 missing) — are extracted as structured text rather than ignored. Define Receiver Signature with a format hint like "Y/N" and the AI detects whether the document contains a signature, regardless of where on the page it appears.

The albarán's handwritten layer is not noise — it is the only field-level record of what actually arrived versus what was supposed to. Ignoring it means your WMS receives incorrect quantities and your three-way match fails at the factura reconciliation stage, where the invoice quantity (based on what was shipped) must be reconciled against what was actually received.

Extracted albarán data feeds directly into Spanish accounting — every field maps to a PGC account code or a WMS transaction.

The output spreadsheet from the extraction is not the destination. It is an intermediate format that bridges the albarán and the systems that need its data. In a Spanish warehouse running Sage 200 or SAP Business One, the extracted fields follow a specific downstream path:

The critical link is the albarán number. Under Spanish commercial practice, the supplier later issues a factura that references the same albarán number. The three-way match — purchase order, albarán (goods received), factura (invoice) — depends on the albarán number and the delivered quantities being correct in the ERP. If manual entry introduces a typo in the albarán number (transposed digits, missing a character), the subsequent factura reconciliation fails and someone has to trace back through paper records to find the correct number. Extraction that pulls the albarán number directly from the document eliminates the most common reconciliation failure point.

For teams that receive albaranes from field staff or drivers rather than at a fixed receiving dock, the Collection Link feature closes the document intake gap. Generate a shareable link, send it to drivers or remote warehouse staff, and albaranes arrive directly in your processing queue — no email attachments, no WhatsApp photos, no registration required for the sender. This is particularly useful for Spanish logistics operations where deliveries happen at multiple sites or where third-party transport companies handle the physical delivery but the receiving data needs to reach a central AP or inventory team.

Frequently Asked Questions

Spanish albaranes carry the weight of a 140-year-old commercial code, the variety of every supplier's ERP output, and the physical evidence of what actually arrived on the dock. The data extraction problem is not speed — it is that the receiving clerk never builds muscle memory, because every albarán layout is a first-time read. Column-name extraction changes the equation: you define what you need once, and the format war becomes irrelevant.

Try It on Your Albaranes

Related: Batch extract packing slips and delivery notes to Excel · Manual vs AI packing slip extraction in warehouse receiving · Extract packing slip fields from any format into Excel · Delivery note to Excel converter