Data Format (CSV, XML, JSON)
A data format defines how data is structured and stored for exchange between systems. CSV, XML and JSON are the three most common data formats in the ERP world: CSV for simple tables, XML and JSON for nested records and interfaces.
A data format (CSV, XML, JSON) is a fixed convention for how data is structured, encoded and stored so that different programs can read and write it unambiguously. It answers the question: "In what form is the information provided so that another system understands it?" CSV, XML and JSON are by far the three most common formats in the ERP and e-commerce world. They differ in how much structure they can represent - from the plain table (CSV) through strictly governed, nested documents (XML) to the lean JSON optimized for web interfaces.
You can think of a data format like the grammar of a language: it is not the content itself that matters, but the rules by which it is written down. If sender and receiver follow the same grammar, they understand each other - no matter which software runs on either side. That is exactly why data formats are the quiet foundation of every data exchange: whether an item master is exported, an order is handed over to a marketplace or a document is sent to accounting - underneath there is always a data format that defines how fields, values and relationships are recorded.
At a glance
- Data format = fixed structure in which data is stored for exchange
- CSV: simple table with a delimiter - ideal for flat lists such as item or price lists
- XML: strictly structured, verifiable via schema - the standard for e-invoicing (XRechnung, ZUGFeRD)
- JSON: lean and nested - the format of modern REST APIs and web interfaces
- A freely chosen format is rare: the target system or a standard usually dictates it
CSV, XML and JSON: the three most important data formats
The three data formats that dominate everyday ERP work solve different tasks and can be distinguished by their structure. Which one is "right" almost never depends on personal taste, but on what the target system, a marketplace or a legal standard requires.
CSV - the simple table
CSV (Comma-Separated Values) is the plainest of the three formats: a pure text file in which each line holds one record and a delimiter - usually a comma or semicolon - separates the individual fields. The first line typically contains the column headings. CSV is excellent for flat, tabular data without nesting, such as item lists, price lists or address exports, and can be opened in any spreadsheet application. Its limit is exactly this simplicity: nested structures - for instance an order with several line items - can only be represented awkwardly, and delimiters, umlauts and character encoding (UTF-8) hold many pitfalls.
XML and JSON - structured formats
XML (Extensible Markup Language) describes data through nested elements with opening and closing tags. It is expressive, strictly verifiable and can be validated against fixed rules via a schema (XSD) - which is why XML is the basis of many formal standards, from e-invoicing to EDI-style formats. JSON (JavaScript Object Notation) pursues the same goal - representing nested data - but is much leaner and easier for humans to read. JSON is the standard format of modern REST APIs and thus what flows most frequently between ERP, shop and cloud services today.
How a data format works
Every data format defines three things: the structure (how fields and records are arranged), the syntax (which characters serve as separators, delimiters or markup) and the encoding (which character set stores letters and special characters, as a rule UTF-8). Only when sender and receiver share the same assumptions about these three levels does the exchange succeed without errors.
The path from one system to another almost always runs through an export and an import: the source system writes its internal data out into an agreed data format, and the target system reads that file back in. Because field names and structure are rarely identical on both sides, this step includes a field mapping - the assignment of which field in the source corresponds to which field in the target. For ongoing connections, a middleware or an ETL process often handles the conversion from one format to another, so that systems which "speak" different formats can still work together.
Data formats in the ERP system
In the ERP system you encounter the data format at almost every interface. For importing and exporting master data, CSV is the classic: new items, prices or customers are loaded in as a CSV file, and reports are pulled out as CSV. As soon as connected systems come into play - online shop, marketplace, payment, shipping - JSON dominates, because the associated REST APIs transfer data in this format. XML, in turn, appears wherever formal standards and verifiability count: in e-invoicing, in EDI environments and at government interfaces.
In practice this means: the data format is rarely freely chosen. A marketplace dictates its product-feed format, the tax office requires e-invoices in a particular XML standard, an API delivers and expects JSON. A good ERP system therefore supports several formats and provides tools to translate between them - via configurable import/export profiles, via connectors to third-party systems or via a connected middleware. If this flexibility is missing, manual rework quickly arises because data has to be reformatted by hand.
Distinction: data format vs. interface and standard
A data format is often confused with related terms but must be clearly separated from them. An interface or API governs the transport path and the rules of communication - who may request what and when. The data format, by contrast, only governs the form in which the transferred data is recorded. Figuratively: the interface is the envelope and its delivery route, the data format the language and grammar of the letter’s content. A JSON response from a REST API is therefore both at once - the API as transport, JSON as format.
Equally, the data format must be distinguished from the functional standard that fills it. XRechnung, ZUGFeRD or EN 16931 are not data formats in the narrow sense, but content rulebooks that prescribe which fields an invoice must contain - and that usually cast these requirements technically in XML. The format (XML) is the technology, the standard the binding meaning on top of it. Anyone who separates the two understands more quickly why a file can be "technically correct XML" and still "not a valid e-invoice".
DACH specifics: encoding, delimiters and e-invoicing
In the German-speaking region, two small details regularly cause trouble in data exchange. First, character encoding: umlauts (ä, ö, ü) and the ß are only transferred correctly if source and target use the same encoding - today usually UTF-8; otherwise the notorious "garbled" characters appear. Second, the CSV delimiter: because the comma serves as the decimal separator in the German number format, many programs in the DACH region use the semicolon as the field separator - if this is mixed up on import, entire columns shift out of place.
Legally, e-invoicing above all shapes the topic of data format. Since 2025, businesses in Germany are required to be able to receive structured electronic invoices in the B2B sector; the decisive rule is the European standard EN 16931, implemented in formats such as XRechnung (pure XML) and ZUGFeRD (XML embedded in a PDF file). A plain PDF or a scan expressly does not count as an e-invoice, because it carries no machine-readable data format. For ERP systems in the DACH region, cleanly mastering these XML-based formats is therefore not optional, but a legal obligation.
Example
Example: item import and outgoing invoices in retail
A mid-sized online retailer receives a new supplier’s assortment as a CSV file with around 4,000 items - a flat table with item number, description, price and EAN. Via an import profile in the ERP, each column is assigned to the matching field in the item master through field mapping; a test run reveals that the file is semicolon-separated and Latin-1 encoded, which is why the umlauts have to be converted to UTF-8 before the import.
At the other end of the process chain sits the outgoing invoice: when the retailer sells to a business customer, the ERP no longer generates a PDF but an XRechnung in XML format according to EN 16931. So the same system that processes the simple CSV import must at the same time output a strictly governed XML - two very different data formats for two very different purposes, both indispensable in day-to-day business.
Frequently asked questions
Related services
Sources
Questions about Data Format (CSV, XML, JSON) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.