.png)
SummaryExporting a list of PZNs is not a button. It is a sequence of decisions. Which articles belong in the file, which fields the target system actually processes, which format, and how often. Teams that settle those four questions first get a file that loads. Teams that skip them get a spreadsheet that someone repairs by hand, every time.
This guide is written for the people who have to make a German pharmaceutical article export work in a system that was not built for it: data teams at international manufacturers, ERP integrators, marketplace operators and analytics groups. It covers the four decisions, the three format traps, the fields that get forgotten and later cost money, and the point at which a file stops being the right delivery mechanism. For a single identifier you only want to look up once, use the free PZN lookup instead.
The Pharmazentralnummer is the eight-digit German identifier for a medicine or pharmacy-typical product, assigned per package by IFA GmbH. It identifies a package, not a product: a different pack size or a different marketing authorisation holder means a different PZN. That single property drives almost everything below, because it means an export is a list of packages, and the number of rows is a function of pack variants rather than molecules.
The data attached to each PZN lives in the German article master. That file carries price, dispensing status, reimbursement flags, pack size, dosage form and supplier per PZN, and it is the layer an export draws from. If that distinction is new, the background is in the pharmaceutical article master explained and in how data enters German drug databases through IFA.
One: which articles? Scope decides everything downstream. Three cuts cover most real requests. The first is your own article list, enriched with market data. The second is a slice of the market by active substance, ATC group or indication. The third is the full national inventory, which is requested often and needed rarely.
Two: which fields? The article master carries a three-digit number of evaluable fields per PZN. An export that takes all of them is not thorough, it is unusable, because nobody maps three hundred columns. The productive question is which fields the target system will actually process, not which fields exist.
Three: which format? CSV, Excel, JSON and XML are all feasible and differ mainly in what happens after delivery. The section on format traps below is the reason this decision is not cosmetic.
Four: once or continuously? A one-off export is a snapshot. A standing delivery is a data subscription with a licence, a cadence and a retention period. These are two different transactions even when the file looks identical.
Most exports do not start from the full market. They start from a list the company already has. The products are in the ERP, and what is missing is the market layer around them: current prices, dispensing status, successor articles, substance data.
Starting there has a practical advantage that is easy to miss. Your list is already the filter. Instead of writing a selection rule and arguing about its edges, you submit your PZNs and get enriched rows back. The result is the size of your assortment, not the size of the market, and the review effort scales accordingly.
The precondition is a clean PZN column, and this is where exports most often fail before they begin. Companies that run on their own material numbers have to establish the mapping first, and that mapping needs maintenance, because articles change. If your internal key is not the PZN, solve that before you scope the export, not after.
Three errors repeat across article data projects, and all three surface only in the target system, usually after the file has been signed off.
The leading zero. A PZN can begin with a zero. Spreadsheet software reads the column as a number and drops it, turning an eight-digit identifier into a seven-digit one, and every join then fails silently for exactly those rows. The fix is to declare the column as text explicitly, or to use CSV rather than a spreadsheet format and set the column type on import. Treat the PZN as a string everywhere in the pipeline, including in the database schema.
The decimal separator. German systems write prices with a comma, most English-locale systems with a point. A file that crosses that boundary without an agreed convention produces either parse errors, which are cheap, or silently misread values, which are not. Put the separator in the specification rather than in the assumptions.
The character encoding. Umlauts in brand names and authorisation-holder names break when export and import assume different encodings. UTF-8 on both sides solves it, but it has to be agreed rather than hoped for. The tell is a product list where a handful of names contain replacement characters and nobody notices until a customer does.
Field requirements follow the purpose. Three cuts cover most cases, and each has one field that is regularly left out and expensively retrofitted.
| Purpose | Core fields | What is usually missing |
|---|---|---|
| Master data reconciliation | PZN, brand name, dosage form, pack size, authorisation holder, dispensing status | successor PZN for delisted articles |
| Price analysis | PZN, prices by price type with valid-from date, reference price, rebate contract flag | the valid-from date, without which a price cannot be attributed to a period |
| Assortment analysis | PZN, ATC code, active substance, strength, prescription status, product group | the substance quantity, without which strengths cannot be compared |
| Cross-border matching | PZN, ATC code, substance, strength, plus GTIN or other national identifiers | the identifier bridge itself, which is a separate data question |
The single most common omission is the successor reference. An article that leaves the market does not leave your historical data. Without a pointer to the article that replaced it, every time series breaks at that row, and the break looks like a decline rather than a renaming.
The second most common is the valid-from date on prices. A price without a date is not a fact, it is a rumour, and in a market where price updates run on a bi-weekly rhythm it stops being true quickly.
An export taken twice is not the same thing as two separate exports. As soon as anyone intends to compare them, three requirements appear.
An as-of date per row. Without it there is no way to say which state a price refers to. Where prices move on a bi-weekly cycle, this is not a refinement, it is the difference between a comparison and a guess.
Stable keys. The PZN is stable, the brand name is not. Anyone reconciling on the name gets a false difference on every rename and a false match on every near-duplicate.
An explicit treatment of departures. An article missing from the second export may have been delisted, or it may have fallen out of the filter. Without a flag those two cases are indistinguishable, and they call for opposite responses. One is a market event you need to act on, the other is an artefact of your own query.
Designed in at the start, these three cost almost nothing. Retrofitted, they mean starting the series again.
The difference is contractual rather than technical, and that catches people out because the file looks the same either way.
A one-off export answers a question at a point in time. It suits an analysis, a reconciliation or a due-diligence exercise. It then ages, faster than most plans assume: the article master is updated daily and price updates run on a bi-weekly rhythm, so a quarterly refresh of a price analysis is working with stale numbers by design.
A standing delivery keeps a dataset current. It needs three things agreed: the cadence, the format, and whether the delivery marks changes. The third is the one most often forgotten and the one that matters most if anyone ever has to show what changed and when.
Anyone planning a delivery should also settle the retention period. The agreed cadence determines how long a given state may be used in your own system. That is a licence question, not an engineering one, and it belongs in the contract rather than the specification. The trade-off between a raw licence and a maintained interface is set out in raw licence versus API for German drug data.
Both deliver the same content. They suit different situations.
| Export | API | |
|---|---|---|
| Fits when | one state is analysed, people work with the file, frequency is low | a system queries at runtime, currency per call matters |
| Effort to start | low, it is a file | higher, integration and error handling |
| Effort afterwards | repeated per run, usually manual | low, it runs with the system |
| Typical failure | the state goes stale unnoticed | too many calls for a job that was an export |
A serviceable rule of thumb: if the file gets opened and read by a person, the export is right. If it only gets loaded so that a system can query it, an interface was probably meant. Most mature setups use both, with a bulk extract for the initial load and full re-syncs, and an interface for incremental changes and lookups by identifier. That pattern, and the evaluation criteria behind it, are covered in pharma data for analytics teams and in how to evaluate a pharmaceutical data API.
An export is not a data licence. What you may do with the file, meaning analyse it, hold it in your own system, or pass it to a third party, is governed by the licence. Holding a file does not imply a right to use it however you like, and this is the point most often discovered late in a procurement.
An export says nothing about availability. Dispensing status and actual supply are two different things. An article can be formally in distribution and still be impossible to obtain, and no article master field will tell you that.
Size is not a quality signal. A full-market export is rarely useful. What makes it useful is the cut, not the row count, and a request for everything is usually a sign that the scoping question has not been answered yet.
pharmazie.com is the consolidated pharmaceutical data platform operated by DACON Datenbank Consulting GmbH, on the market since 1989. It brings 25+ pharmaceutical databases into a single search, the Eisbergsuche®, and is addressed exclusively to healthcare professionals rather than patients. For export purposes three points matter: the German article master supplies the package-level fields keyed on the PZN, product data covers 50+ countries where a question runs past the German market, and price data is focused on DACH with further countries following. Portal access starts at 135 EUR per month, net plus VAT; the current scope is on the pricing page.
A usable PZN export starts with four decisions: scope, fields, format, frequency. The three errors that cost the most time are all format errors, namely truncated leading zeros, inconsistent decimal separators and broken encodings. Anyone moving to a standing delivery should additionally settle whether changes are marked and how long a given state may be held. And if the file is only being loaded so a system can read it, the question was never really about a file.
If you want to hold a field set against your own specification, book a demo and bring the spec.
This content is addressed to healthcare professionals and does not constitute medical advice. Last reviewed: September 2026.
