The Nabisy CSV format is BLE’s structured file for bulk submission to Nabisy, Germany’s federal registry for sustainability proofs. The BLE runs Nabisy. Any biofuel sustainability claim relevant to the German market has to be registered there. Below a handful of consignments, typing each one into the web interface by hand is manageable. Past that, it isn’t, which is why BLE also accepts the structured CSV.
The Nabisy CSV format is exact: forty-one required columns, a fixed field order and no tolerance for a missing value. As a result, it rewards precision in a way a hand-typed spreadsheet rarely survives at volume.
This article walks through what the CSV actually requires, field by field where it matters. It also shows where manually built submissions tend to fail once volume picks up.
What the Nabisy CSV format actually asks for
Each outgoing PoS becomes one row in the file, and every row carries the same required structure:
- NACHWEIS_ID combines the issuing party’s Schnittstelle (interface identifier) with a unique suffix per sub-PoS. Sometimes one incoming consignment splits across several outgoing proofs. In that case, each split gets its own suffixed ID instead of reusing the parent identifier.
- VERBINDUNGSDOKUMENT is the field that does the real traceability work. It links each outgoing PoS one-to-one back to the NTNw of the specific incoming PoS it was allocated from. This mechanism lets BLE, or an auditor, trace any outgoing claim back to exactly the incoming proof it came from. In other words, the trail doesn’t end at a pool of undifferentiated inventory.
- EMISSIONS goes in as a single pipe-separated string, in a fixed positional order: e_ec (extraction and cultivation), e_l (annualised land-use change), e_p (processing), e_td (transport and distribution), e_u (emissions from fuel in use) and e_sca (the emission-saving credit for improved agricultural management). Because the format is positional rather than labelled, the string has to keep empty positions even when a component doesn’t apply.
- Volumes go in as kWh on an LHV basis. They also have to reconcile, within a defined rounding tolerance, against the incoming PoS they were allocated from.
- Country of origin, feedstock code and waste-or-agricultural classification all have to carry through unchanged from the incoming proof to the outgoing one. After all, these are exactly the attributes an auditor would check first if anyone ever questioned a claim.
Where hand-built submissions actually fail
The format doesn’t leave much room for a small mistake to stay small:
- A decimal or separator error anywhere in the EMISSIONS string breaks the parsing of the entire field, not just the one component that was wrong.
- A single missing required column rejects the whole file. What’s more, the rejection gives no row-level detail on which entry caused it.
- A mismatch between incoming and outgoing volume often goes unnoticed until after BLE has already accepted the file. That’s a considerably worse place to find it than before submission.
- Terminal-specific increments, meaning EP Gate and ETD adjustments applied per truck slot, end up inconsistent when someone calculates them by hand across many rows.
- Most operations maintain the mapping between a biomethane product code and its liquefied bio-LNG counterpart manually. That mapping drifts quietly over time as codes or product lines change.
None of these are conceptual misunderstandings of what Nabisy wants. Instead, they’re small, structural errors. A rigid, positional, 41-column format will always surface them eventually, usually at the least convenient point in the process.
Where FuelFWD fits
FuelFWD generates the Nabisy CSV directly from the incoming PoS, rather than treating it as a file to build by hand:
- FuelFWD ingests the incoming Nabisy PoS PDF directly. It extracts NTNw, supplier and recipient details, country, feedstock code, volume and the full emissions breakdown automatically. Nobody retypes anything.
- The submission runs through the standard mass balance and validation flow. Instead of a PDF PoS, it produces a Nabisy-ready CSV with all 41 columns populated correctly.
- The platform enforces one-to-one matching. Each outgoing PoS links back to exactly one incoming NTNw via VERBINDUNGSDOKUMENT. Volume stays within tolerance, and country and waste/agricultural classification carry through unchanged.
- FuelFWD validates the file before export, checking volume preservation, required-field completeness, EMISSIONS string formatting and product code mapping. You get row-level feedback rather than a single rejected file.
- Reconciliation against the BLE Kontoauszug happens once it arrives. That way, an acceptance issue surfaces immediately rather than at the next audit.
- Output format is flexible per customer. The same incoming PoS can become a Nabisy CSV row for one delivery and an ISCC PDF for another. That choice sits at sales-contract level.
The takeaway: the Nabisy CSV format rewards consistency
The Nabisy CSV format is exacting by design. That’s precisely why manual submission processes tend to work fine at low volume. Then they start failing, quietly at first, as soon as volume and truck slots multiply.
Getting the format right isn’t really about understanding what Nabisy wants. Rather, it’s about consistently producing exactly that structure, row after row. That means avoiding the small transcription errors that a rigid, positional format has no tolerance for.
See a real incoming PoS turned into a Nabisy-ready CSV, end to end. Explore FuelFWD’s Nabisy submission.