JCSV file format Version 1.1

JCSV is a UTF-8, self-describing, human and AI-friendly, line-oriented JSON format for storing tabular data. A JCSV file can include metadata as JSON objects and data as JSON arrays. It can also include semantic information that helps AI services understand the content more easily.

Unlike traditional CSV, JCSV can include multiple tables or structured data sections in a single document, making it suitable for software interoperability, AI-assisted data analysis, and long-term data archival.

Version 1.1 is an evolution of JCSV 1.0. It is still under development and introduces features intended to make the format more AI-friendly, self-descriptive, and reliable for preserving reusable data over time.

Naming

JCSV stands for JSON CSV. The name reflects the purpose of the format: to preserve the simplicity and line-oriented nature of CSV while using JSON syntax to represent both metadata and data values in a structured and unambiguous way.

Example of a JCSV and CSV equivalent 

This is a typical CSV file with Accounts information and balance

Account,Description,Balance
1000,Cash on hand,1290.3
1020,Bank account,10
2000,Suppliers,-10

and the JCSV equivalent, where the "columnNames" metadata line contains the list of columns in the sequence of the data..

{"jcsv":{"version":"1.1"}}
{"document":{"topic":"Financial Data","region":"General"}}
{"table":{"name":"Accounts","header":"Accounts"}}
{"columnNames":["Account","Description","Balance"]}
["1000","Cash on hand",1290.3]
["1020","Bank account",10]
["2000","Suppliers",-10]

JCSV principles

A JCSV file is composed of physical independent lines. JCSV has similarities with the JSON Lines format (JSON-NL). 
Each JCSV element, either metadata or data, is written on one line and is either a metadata line or a data line.

• Metadata lines are valid JSON objects. They contain metadata, declarations, or control information. 
  • Starts with "{" and ends with ""}"
  • jcsv, document, tableSemantics, table, columnNames, and columns are metadata lines.
• Data lines are valid JSON arrays.
  • Starts with "[" and ends with ""]"
  • They contain tabular values in the same sequence defined by the current columnNames line.
  • A data line represents one tabular row.
• Comments lines that start with "//" and are ignore
  • Example
    // This is a comment
• Empty lines are ignored. 
• Other lines 
  • In strict validation mode, non-empty lines that are not metadata lines "{}", data lines "[]", comments lines "//" are errors.
  • In permissive reading mode other non-JCSV valid line may also be ignored. 

All JCSV records are valid JSON values, so parsing does not depend on separators, quoting conventions, or locale-specific parameters.

The JCSV file structure

A JCSV file may contain file-level metadata, semantic sections, and one or more table sections.
For more information regarding the elements see the section "JCSV format specification".

• Metadata regarding the file
  • jcsv: required. Identifies the content as a JCSV file and declares the format version.
  • generator: optional. Contains information about the application that generated the file.
  • document: optional. Contains information about the document.
  • tableSemantics: optional. Contains information in a table format, that helps understand the JCSV format and interpret the data.
• Table metadata and data
  Tables are the fundamental building blocks of a JCSV file. A file consists of one or more tables. 
  Each table starts with a JSON table header object, may be followed by table metadata objects, and contains zero or more JSON data row arrays.
  • table: required . Starts a new table section.
  • columnNames: required for table data. Contains the list of columns and their sequence. Equivalent to the header in CSV.
  • columns: optional. Contains additional information about the columns.
  • data lines: One or more JSON arrays containing the columns data, in the sequence specified by columnNames.

JCSV Example with Atmospheric Observations

This is a more complete JCSV example that contains information about atmospheric observations. There are two tables, "Locations" and "Observations". The "semantics" section contains information that allows the AI to correctly interpret values, such as the unit "mm" for rainfall and the source reference for "Locations.StationId".

Try giving this text to an AI tool, and you will see that it will immediately understand the format and provide you with accurate information.

// text that is not within {} or [] is ignored 
{"jcsv" : {"version" : "1.1", "encoding":"UTF-8"}} 
{"generator":{"createdAt":"2026-05-06T09:00:00Z","name":"MeteoLink-Pro","version":"2.4.0"}} 
{"document":{"region":"Lugano, Switzerland","stationId":"LUG-S01","topic":"Atmospheric Observations","coordinates":{"lat":46.0037,"lon":8.9511}}} 

// start tableSemantics
{"tableSemantics":{"description":"Semantic information, in table format, for interpreting tables, columns, and data roles", "type": "meta"}}
{"columnNames":["TableName","ColumnName","Role","Reference","Unit","Description"]}
["Observations","Timestamp","PrimaryKey","","ISO-8601","Unique temporal identifier for the reading"] 
["Observations","Temp","ObservationValue","","°C","Air temperature at 2 meters altitude"] 
["Observations","Rainfall","ObservationValue","","mm","Cumulative precipitation for the hour"] 
["Observations","StationStatus","StatusFlag","","","Indicates if the sensor was operating within parameters"] 
["Observations","Source","SourceReference","Locations.StationId","","Links data to the station ID in the locations table"]
["Locations","StationId","PrimaryKey","","","Unique identifier for the weather station"]
["Locations","Name","Context","","","Natural language name of the site"]
["Locations","Altitude","Measurement","","m s.l.m.","Elevation above sea level"]
["Locations","Lat","Coordinate","","decimal","Latitude"]
["Locations","Lon","Coordinate","","decimal","Longitude"]

// start table Locations
{"table":{"name":"Locations","header":"Monitoring Stations Locations"}}
{"columnNames":["StationId","Name","Altitude","Lat","Lon"]}
{"columns":[{"name":"StationId","type":"string"},{"name":"Name","type":"string"},{"name":"Altitude","type":"number"},{"name":"Lat","type":"number","decimalPlaces":4},{"name":"Lon","type":"number","decimalPlaces":4}]}
["LUG-S01","Lugano Centro",273,46.0037,8.9511]
["LUG-S02","Monte Brè",925,46.0061,8.9831]

// start table Observations
{"table":{"name":"Observations","header":"Weather Observations hourly"}}
{"columnNames":["Timestamp","Temp","Rainfall","StationStatus","Source"]} 
{"columns":[{"name":"Timestamp","type":"datetime"},{"name":"Temp","type":"number","decimalPlaces":1},{"name":"Rainfall","type":"number","decimalPlaces":2},{"name":"StationStatus","type":"string"},{"name":"Source","type":"string"}]}
["2026-05-06T07:00:00Z",14.2,0.00,"OK","LUG-S01"] 
["2026-05-06T08:00:00Z",15.8,0.00,"OK","LUG-S01"] 
["2026-05-06T09:00:00Z",16.1,0.45,"WARNING","LUG-S01"]

Why JCSV is AI-friendly

JCSV is more self-descriptive than CSV, simpler than XML, more readable than binary formats, and better suited to complex tabular data than a single large nested JSON file. 
It is therefore a very suitable format for sharing information that needs to be interpreted by AI tools.

• Unambiguous parsing: unlike CSV, JCSV does not depend on field separators, quoting rules, empty lines, or locale-specific conventions.
• Explicit column order: columnNames clearly maps array values to column names.
• Multiple tables in one file: related data can stay together instead of being split across many CSV files.
• Rich metadata support: columns can describe types, formats, constraints, decimals, and descriptions.
• Semantic layer: can explain roles, relationships, keys, references, units, and meanings.
• Less ambiguity: AI does not need to guess what columns or codes represent.
• Lower computational overhead: explicit structure and semantics can reduce inference, clarification, and error-correction work during AI-assisted analysis.
• Line-oriented structure: each line is either metadata {} or data [], making parsing simple and predictable.
• Plain text format: easy for AI systems to read, inspect, and reason about.
• Stream-friendly: files can be processed sequentially, even when large.
• Human-readable: both humans and AI can understand the file without specialized binary tools.
• Good balance: combines the simplicity of CSV with the context usually missing from CSV.

Why JCSV is suitable for long-term data preservation

• Human-readable: future users can inspect the file with a simple text editor.
• Plain text format: data remains readable without depending on a specific application or binary format.
• Based on JSON syntax: uses a widely known, stable, and well-supported data representation.
• Unambiguous parsing: avoids common CSV issues such as separators, quoting rules, empty lines, and locale-dependent formatting.
• Self-describing structure: metadata, table names, columnNames, and optional columns help future users understand the file.
• Multiple tables in one file: related datasets can be preserved together, reducing the risk of losing context between separate files.
• Reusable by data-management applications: tables, column names, metadata, and relationships can be imported or mapped into databases, spreadsheets, ETL tools, and analysis software.
• Semantic information: semantics can document roles, relationships, references, units, and meanings that might otherwise be lost.
• Software-independent: the file can be interpreted without the original program that created it.
• Versionable: the jcsv metadata can include a format version, helping future parsers apply the correct rules.
• Stable for archival workflows: the line-oriented structure is easy to validate, diff, store, compress, and checksum.
• Good balance: combines the longevity of plain text with more structure and context than traditional CSV.

JCSV format specification

See example below.

• UTF-8 character encoding.
  The UTF-8 encoding is mandatory. 
• Line-delimited JSON format in which each physical line contains one complete JSON value.
  • Line endings must use LF, Line Feed, U+000A ("\n"). 
    Readers should also support CRLF, U+000D U+000A ("\r\n"), for compatibility, but a standalone CR, U+000D ("\r"), must not be considered a valid line break.
  • Writers should always emit LF line endings and omit CR characters.
  • LF must be used only to terminate physical lines and must not occur unescaped inside a data or metadata line. If a text value requires an internal line break, it should use LS, Line Separator, U+2028, or another appropriate application-defined replacement or escaping convention.
• Metadata lines
  • Meta data line start "{" and end with the  "}" brackets.
  • A metadata line is a valid JSON object encoded on a single physical line. 
  • It contains one top-level JCSV property.
  • The value of the property depends on the metadata type. 
    • Most metadata properties, such as jcsv, document, generator, table, rowStyle, and rowErrors, use a nested JSON object. 
    • Some properties, such as columnNames, use a JSON array.
  • White-space inside a metadata line is allowed by JSON, but writers should prefer compact JSON and must not insert physical line breaks inside a JCSV record.
  • Metadata lines usually apply to the records that follow them. 
    • For example, a table line starts a table section, and the following data lines belong to that table until another table, document, or section declaration is found.
    • Row-level metadata, such as rowStyle or rowErrors, applies only to the next data line unless otherwise specified.
  • Reserved metadata keywords:
    • Standard JCSV property names use lower camelCase (for example: rowStyle, fontSize). 
    • Property names are case-sensitive.
    • "jcsv" is required and should be the first JCSV record. 
      • It identifies the file as JCSV and declares the format version. 
      • The version property is required. 
      • The encoding property is optional and, when present, must be "UTF-8".
      • Example
        {"jcsv" : {"version" : "1.1", "encoding":"UTF-8"}} 
    • "generator" contains information regarding the application that has generated the file.
      • Example
        {"generator":{"name":"BananaPlus","version":"10.2.7"}} 
    • "document" contains information regarding the file.
      • Add any element that may be helpful to understand the data, like name, header, description, etc.
      • All successive elements before the next "document" should be belonging to this document.
      • Example:
        {"document":{"topic":"Atmospheric Observations","coordinates"}} 
    • "tableSemantics" is a table element containing information that help interpret the content.
      • The tableSemantics metadata line may introduce a semantic table. 
        If followed by columnNames and data lines, those lines belong to the semantics section until the next table, document, or other section declaration.
      • The tableSemantics section is similar to a table, but has its own tag to avoid conflict with a possible user table named "tableSemantics"
    • "schema" reserved keyword for later use. 
    • "provenance" information regarding the provenance of the data. It can be used at the document or the table level.
      • {"provenance":{"www":"www.example.com"}}
    • "table" contains the name of a table.
      • Add any element that may be helpful to understand the data, like name, header, description, etc.
      • All rows following the "table" are considered to belong to this table.
      • A table section continues until the next table declaration, the next document declaration, or the end of the file.
    • "columnNames" is a mandatory element that contains a JSON Array with the columns names.
      • It is the equivalent of the "header" in CSV files.
      • The data rows following the columns are considered to be in the sequence of the columns name.
      • It should immediately follow the table element.
        A "columnNames" that does not follow a "table" is an error and a start a new table.
      • Example:
        {"columnNames":["StationId","Name","Altitude","Lat","Lon"]}
    • "columns" is an optional element that contains and JSON Array with information relative to the columns.
      • Each columns":[{"name":"Timestamp","type":"datetime"
      • columns element should follow the columnNames element
      • In the columns element, the columns sequence does not need to be in the same sequence of the data. 
      • Each column should have a 
        • "name" that is the same as the on in the element columnNames
          Should be used to access the column information.
        • "type", additional information to interpret the column data and format (string, date, amount).
      • Example:
        {"columns":[{"name":"StationId","type":"string"},{"name":"Name","type":"string"},{"name":"Altitude","type":"number"},{"name":"Lat","type":"number","decimalPlaces":4},{"name":"Lon","type":"number","decimalPlaces":4}]}
    • "rowErrors" contains information regarding errors at the row level.
      • line applies only to the next data line.
    • "rowStyle" contains supplementary information regarding the following data row.
      • line applies only to the next data line.
      • Example
        {"rowStyle":{"bold":true,"fontSize":10}}
    • Custom metadata. 
      • It is possible to add application-specific properties. 
      • Possibly use lower camelCase unless a namespace or extension convention defines otherwise.
• Data lines.
  Data lines contain the actual tabular data. 
  • They should be preceded by the "table" and "columnNames".
  • A data line is a JSON array encoded on a single physical line. 
  • The line starts with the "[" and terminate with the "]" .
  • The sequence and number of elements within the data array must be the same as the columns defined in the preceding element "columnNames".
  • Data is stored in JSON format.
    • Reader should easily understand the type of information.
    • Strings are enclosed in double quotes.
      • Usual string "Bank account".
    • Date, Time and Timestamp are JSON string in the ISO date format 8601
      • Date  "2018-01-03".
      • Time "10:18:21.000".
      • Timestamp "2016-11-19T09:52:39".
    • Number in valid JSON format, decimal separator "."
    • true or false.
    • null.
• Empty lines are allowed, but not considered.
• Other lines not being a valid JSON Object or not an empty line are considered an error.
  • Strict mode: invalid/non-JCSV lines are errors.
  • Permissive mode: empty and non-JCSV text lines may be ignored.
  • Formal comments should be encoded using the comment metadata property.
    {"comment":{"text":"This file contains atmospheric observations."}}

Semantics information - tableSemantics 

The tableSemantics section is structured as a table and contains information that helps AI services understand the structure and content of the file. The element includes a description and the type "meta", which indicates that it contains metadata.

Columns of the tableSemantics

Like other tables, it is followed by a columnNames element and the related semantic data, organized in the following columns:

• TableName
  Target table name these semantics apply to. An empty value means the row describes the behavior of the whole file, applying to every table (symmetric with ColumnName: empty TableName = whole file, empty ColumnName = whole table
• ColumnName
  Specific column within the target table. An empty value means the row describes the behavior of the whole table.
• Role
  Examples: SourceTable; MetadataTable; PrimaryKey; ForeignKey; Amount; DerivedTable; ReportTable; VirtualColumn
  Semantic classification of a table, column, or metadata entry. Defines its function in the data model (e.g. key, measure, metadata, or calculated/extracted column).
• Reference
  Syntax: TableName.ColumnName; separator: ;","","Related table, column, source table or accepted value list. 
  Use TableName.ColumnName for column references and semicolon-separated values for multiple references.
• Unit
  Unit of measure or currency code for column values. Examples: EUR; CHF; USD; %; kg","mm","meters".
• Description
  Clear explanation for AI and human interpretation. Keep the text simple, direct and focused on a single concept.

JCSV semantics

The JCSV is based on JSON and is self explaining, but is not a well know format, so in order to avoid ambiguity it is advisable to add, at the begin at the tableSemantics, information regarding the JCSV format and how the file is structured and how it should be interpreted. 
 

{"tableSemantics":{"description":"Semantic information, in table format, for interpreting tables, columns, and data roles", "type": "meta"}}
{"columnNames":["TableName","ColumnName","Role","Reference","Unit","Description"]}
["tableSemantics","","MetadataTable","","","Semantic map of the JCSV file. Helps AI and software interpret tables, columns, relationships, conventions and derived data. This table contains metadata, not financial or accounting data."]
["tableSemantics","TableName","FieldDefinition","","","Target table name these semantics apply to. An empty value means the row describes the behavior of the whole file, applying to every table (symmetric with ColumnName: empty TableName = whole file, empty ColumnName = whole table)."]
["tableSemantics","ColumnName","FieldDefinition","","","Specific column within the target table. An empty value means the row describes the behavior of the whole table."]
["tableSemantics","Role","FieldDefinition","Examples: SourceTable; MetadataTable; PrimaryKey; ForeignKey; Amount; DerivedTable; ReportTable; VirtualColumn","","Semantic classification of a table, column, or metadata entry. Defines its function in the data model (e.g. key, measure, metadata, or calculated/extracted column)."]
["tableSemantics","Reference","FieldDefinition","Syntax: TableName.ColumnName; separator: ;","","Related table, column, source table or accepted value list. Use TableName.ColumnName for column references and semicolon-separated values for multiple references."]
["tableSemantics","Unit","FieldDefinition","Examples: EUR; CHF; USD; %; kg","","Unit of measure or currency code for column values."]
["tableSemantics","Description","FieldDefinition","","","Clear explanation for AI and human interpretation. Keep the text simple, direct and focused on a single concept."]
["tableSemantics","*","VirtualColumn","","","Defines a logical column that is not explicitly stored in the data row array, but is parsed or derived from existing column values using specific prefix or formatting rules (e.g., Cost Centers '.' or ',' and Segments ':')."]
["_format","JCSV","structure","","","Format structure is JSON-Lines (JCSV), where each line is a valid independent JSON entity."]
["_format","Table","buildingBlock","","","Tables are the fundamental building blocks of a JCSV file. A file consists of one or more tables. Each table starts with a JSON table header object, may be followed by table metadata objects, and contains zero or more JSON data row arrays."]
["_format","TableHeader","parsingRule","","","A JSON object containing 'table' starts a new table. A JSON object containing 'tableSemantics' starts the reserved system table named 'tableSemantics'. These are the only objects that start a new table."]
["_format","tableSemantics","systemTable","","","The tableSemantics entity is a JCSV system table containing structural and semantic definitions for the file. It uses the reserved 'tableSemantics' header instead of the general 'table' header, while its column definitions and data rows follow the same rules as other JCSV tables."]
["_format","JsonObject","metadataFormat","","","Lines starting with '{' are JSON objects. A JSON object may start a table or define metadata for the current table, such as 'columnNames' and 'columns'."]
["_format","JsonArray","dataRowsFormat","","","Lines starting with '[' are positional data rows belonging to the current table."]
["_format","ParsingRule","parsingRule","","","A data row array belongs to the most recently declared table. Objects such as 'columnNames' and 'columns' describe the current table but do not start a new table. The current table changes only when a new 'table' or 'tableSemantics' header object is encountered."]
["_format","IgnoredLines","parsingRule","","","Empty lines and comment lines starting with '//' must be ignored during parsing."]
["_format","JsonTypes","dataTypeRule","","","Native JSON types used in data arrays: string, number, boolean, null."]
["_format","ColumnTypes","dataTypeRule","","","Semantic column types (e.g. 'date', 'time', 'timestamp', 'amount', 'account') are specified in the 'type' property of 'columns'."]
["_format","DateTimeTypes","typeConvention","","","Temporal values are ISO 8601 strings: date (YYYY-MM-DD), time (hh:mm:ss), timestamp (YYYY-MM-DDThh:mm:ssTZD)."]
["*","columnNames","StructuralDefinition","","","Ordered array of column names (e.g. 'columnNames' or 'fields'). Defines the authoritative positional mapping for subsequent data row arrays (index N -> column N)."]
["*","columns","AdditionalMetadata","columnNames","","Array of column metadata objects (type, description, constraints). Matches column names via the 'name' property, may be independent of the columnNames columns order."]

Semantics regarding user defined tables and columns

It is advisable that you add semantic information for each table and column you are using within your file.

["Accounts","","table","","","Contains the account list, account metadata, balances, grouping, contact data and banking information"]
["Accounts","SysCod","SystemField","","","Internal system code. Usually empty or reserved for application use"]
["Accounts","Links","ExternalLinks","","","Links to external documents or related resources"]

The tableSemantics is structured but has been defined separately to prevent conflicts with user having a tableSemantics. 

Banana Accounting Export to JCSV

From Banana Accounting you can export in JCSV:

• A single table with 
  Menu > Data > Export > Export JCSV
• All the accounting file with 
  Menu > File > Export File > Export JCSV

AI use of JCSV

The JCSV file format, which includes all file data and semantic information, is very suitable for use with AI and large language models (LLMs).

These models can easily interpret the data and provide valuable information about your financial situation and accounting data.

• To protect the privacy of your data, you should use a local LLM.
• If you do not mind sharing detailed accounting information, you can also use ChatGPT, Google Gemini, or other AI models.
   

Banana Accounting Import from JCSV

• Open or drag a JCSV file in Banana
  Banana will create a new file tables and columns. You can then copy and paste the data in Excel.

Programmatically Generating the JCSV

To generate a JCSV file, you can use the JSON functions that each programming language provides. This makes it much easier and simpler than creating a CSV file.

1. Create a JSON object that contains a JSON array with the column names, convert it to JSON text, and add a line feed.
2. For each data row, create a JSON array that contains the data, convert it to JSON text, and add a line feed.

The following is a simple example in JavaScript that uses JSON.stringify.

// JavaScript: Create a JCSV document

var text = "";

// JCSV format declaration
text += JSON.stringify({ "jcsv": { "version": "1.1" } }) + "\n";

// Document metadata
text += JSON.stringify({ "document": { "topic": "Financial Data", "region": "General" } }) + "\n";

// Table declaration
text += JSON.stringify({ "table": { "name": "Accounts", "header": "Accounts" } }) + "\n";

// Column names
text += JSON.stringify({ "columnNames": ["Account", "Description", "Balance"] }) + "\n";

// Data rows
text += JSON.stringify(["1000", "Cash on hand", 1290.3]) + "\n";
text += JSON.stringify(["1020", "Bank account", 10]) + "\n";
text += JSON.stringify(["2000", "Suppliers", -10]) + "\n";

console.log(text);

Parse the JCSV file

1. Read each line.
   • If a line starts with "{" and ends with "}", parse it as JSON and extract the values. 
   • The "table" object marks the start of a new table.
   • The "columnNames" object contains the list and sequence of the CSV data that follows.
2. If a line starts with "[" and ends with "]", parse it as JSON and extract the data.
    

Simple JCSV parser

/* JavaScript to read a JCSV, separate Metadata from Data */
var lines = text.split(/\r?\n/);

for (var i = 0; i < lines.length; i++) 
{
  var line = lines[i].trim();

  // Metadata or control lines (JSON objects)
  if (line.startsWith("{") && line.endsWith("}")) 
  {
    var object = JSON.parse(line);
    console.log("Metadata line:", object);
  }
  // Data rows (JSON arrays)
  else if (line.startsWith("[") && line.endsWith("]")) 
  {
    var row = JSON.parse(line);
    console.log("Data row:", row);
  }
  // Empty lines or unformatted comments are ignored
}

Parsing the JCSV Atmospheric Observations

This JavaScript reads the JCSV Atmospheric Observations and extracts and prints the observation data in JSON format.

// JavaScript: Read JCSV data and create a JSON object with the Observations table

var lines = text.split(/\r?\n/);
var currentTable = "";
var columnNames = [];
var observations = [];

for (var i = 0; i < lines.length; i++) {
  var line = lines[i].trim();

  if (!line.startsWith("{") && !line.startsWith("[")) {
    continue;
  }
  // In production code you should include this section int try
  var value = JSON.parse(line);

  if (value.table) {
    currentTable = value.table.name;
  }
  else if (value.columnNames) {
    columnNames = value.columnNames;
  }
  else if (Array.isArray(value) && currentTable === "Observations") {
    var observation = {};

    for (var j = 0; j < columnNames.length; j++) {
      observation[columnNames[j]] = value[j];
    }

    observations.push(observation);
  }
}

console.log(JSON.stringify(observations, null, 2));

/* Result in JSON format
[
  {
    "Timestamp": "2026-05-06T07:00:00Z",
    "Temp": 14.2,
    "Rainfall": 0,
    "StationStatus": "OK",
    "Source": "LUG-S01"
  },
  {
    "Timestamp": "2026-05-06T08:00:00Z",
    "Temp": 15.8,
    "Rainfall": 0,
    "StationStatus": "OK",
    "Source": "LUG-S01"
  },
  {
    "Timestamp": "2026-05-06T09:00:00Z",
    "Temp": 16.1,
    "Rainfall": 0.45,
    "StationStatus": "WARNING",
    "Source": "LUG-S01"
  }
]
*/ 

History of JCSV

The JCSV specification was conceived and developed in 2016 by Domenico Zucchetti, founder and CEO of Banana.ch and creator of Banana Accounting. Its aim was to create a format that was as simple as CSV but could be parsed without ambiguity and contain multiple tables and metadata. He developed a line-based text format using JSON elements that clearly separated data from metadata. He then implemented export functions in Banana Accounting using the JCSV format, both for individual tables and for complete accounting data. The format proved very useful for sharing accounting data with other systems.

In April 2026, a colleague informed Domenico that AI tools could understand the JCSV format well, thanks to its simple structure and its ability to combine metadata and data. We saw the possibility of providing an AI engine with complete accounting data so that it could analyze the information. We revised the JCSV format to remove some inconsistencies and make it more AI-friendly.

We also realized that the information normally used to define a database was not sufficient to fully understand the data and extract useful information from it. We considered the possibility of reusing the data after a long period of storage. It became clear that mixing metadata and data within the same file could make it possible to add semantic information that better explains the content and the relationships between the data.

The results seemed very promising, so we published JCSV version 1.1, with the idea that it could be the first step toward further testing and improvements to the format.

Domenico Zucchetti has more than 40 years of experience in international accounting, as well as experience as a legal expert and software developer. He has been a blockchain pioneer. In 2002, he was the first to implement a blockchain certification feature in accounting software.

Feedback

We welcome any feedback.