Nabisy submissions, without retyping a single field
FuelFWD takes the incoming Nabisy PoS PDF, runs it through your standard mass balance and validation flow, and outputs a Nabisy-ready CSV instead of a PDF PoS. The 41-column file is composed correctly the first time, with NTNw linking, emissions string, and all required references in place.
The gap
What the rule asks for vs. what spreadsheets deliver
What Nabisy requires vs how operators still build the file
Nabisy is the German federal ledger for sustainability proofs. The bulk CSV upload is the only practical way to register at volume, and the format leaves no room for interpretation. The CSV upload spec requires:
- A 41-column row per outgoing PoS, no missing required fields
- NACHWEIS_ID composed from the issuing party’s Schnittstelle plus a unique suffix per sub-PoS
- VERBINDUNGSDOKUMENT linking 1-on-1 to the incoming PoS NTNw
- EMISSIONS as a pipe-separated string in fixed positional order (e_ec, e_l, e_p, e_td, e_u, e_sca)
- LHV-based kWh volumes with rounding tolerance against the linked incoming PoS
- Country of origin, feedstock code, and waste/agri classification preserved across the chain
Why hand-built CSVs slip through audit
Most operators today either type into the Nabisy web interface row-by-row, or maintain an internal spreadsheet template that gets copy-pasted into the upload. Both approaches create the same failure modes when volume grows:
- Decimal and separator mistakes break the EMISSIONS string parsing
- One missing required field rejects the entire file with no row-level feedback
- Incoming-to-outgoing volume mismatches surface only after BLE acceptance
- EP Gate and ETD increments applied inconsistently across truck slots
- Manual mapping between biomethane product codes (271129-…) and their liquefied counterparts (2711-LNG-…) drifts over time
How FuelFWD turns the Nabisy PDF into a registry-ready CSV
Three capabilities that replace the spreadsheet template and the manual upload with a flow that runs end-to-end.
PDF in, structured data out
The incoming Nabisy PoS PDF is ingested with NTNw extraction, supplier and recipient details, country, feedstock code, volume, and the full emissions breakdown. No retyping.
Standard flow, Nabisy output
The platform runs your usual mass balance and validation steps. At the end, FuelFWD generates a Nabisy-ready CSV with all 41 columns populated correctly, instead of a PDF PoS.
1-on-1 matching enforced
Each outgoing PoS links back to exactly one incoming NTNw via VERBINDUNGSDOKUMENT. Volume preserved within rounding, country and waste/agri classification carried through.
Questions about Nabisy submission
- Yes. The output format is decided per customer at sales contract level. The same incoming PoS can be converted to a Nabisy CSV row for one delivery and an ISCC PDF for another.
- From the individual e_ec, e_l, e_p, e_td, e_u, and e_sca components. The string follows the Nabisy positional order with empty positions preserved. Terminal-specific increments (EP Gate, ETD per truck slot) are applied per your configuration.
- Each incoming PoS becomes one outgoing PoS with a suffix (Main, A, B, C and so on). The CSV gets one row per sub-PoS, and NACHWEIS_ID is generated automatically with the correct suffix.
- Yes. Volume preservation, required-field completeness, emissions string formatting, and biomethane-to-LNG product code mapping are all checked before export. Mismatches are flagged with row-level feedback.
- Yes. Once your incoming Kontoauszug arrives, FuelFWD matches it back against the outgoing CSV submission, so you catch any acceptance issues before the audit does.
Related use cases
Keep exploring how FuelFWD handles compliance
Ready when you are
See your own incoming PoS turn into a Nabisy CSV
We’ll load a real PoS from your operation into a FuelFWD environment and walk through the full Nabisy CSV generation, end to end.