Working with data
Supported formats
Give VLDTION the export you already produce. This page is generated from the adapters that are actually registered in the build, so it says what the software does rather than what the roadmap hopes for.
What is read today
BKMVDATA, uniform file structure
SupportedRecords classified, structure validated against the file, and fields read at the positions specification 1.31 declares.
Hashavshevet, MOVEIN interface
SupportedFixed-width journal transactions read at the positions the accompanying MOVEIN.PRM declares, including the allocation-number field.
Delimited text (CSV, TSV)
SupportedAny delimited export, with columns mapped once from a dictionary of English and Hebrew header names.
Excel workbook (XLSX)
SupportedWorkbook values as the spreadsheet stored them. Formulas are never evaluated.
Bank statement (CSV, XLSX)
SupportedThe export your bank already produces, with columns recognised by name in Hebrew and English, including a currency column and a rate column where the statement carries them. Bank-specific fixed-width interchange files are not implemented: no bank publishes their record layout.
Priority. Native export
Not supported nativelyPriority exports are user-configurable form exports, and no public specification defines their columns. Priority data reaches VLDTION through the uniform file structure that every registered Israeli accounting system must produce, or through Excel with a column mapping.
The uniform file is the route that always works
Every accounting system registered in Israel must be able to produce the uniform file structure, INI.TXT and BKMVDATA.TXT. VLDTION reads that natively, field by field, against the Tax Authority’s own specification. Whatever a practice runs, that export exists, which is why it is the format to reach for first.
Formats that need a second file
A Hashavshevet MOVEIN export is fixed-width with no header row: the positions live in the MOVEIN.PRM that was produced with it. VLDTION recognises the data file, refuses to read it against an assumed layout, and asks for the parameter file. Once both are present it reads every field the parameter file declares, and reports the ones it leaves at zero as absent rather than empty.
Partial data is a first-class answer
No export carries everything. Each rule declares the fields it needs, and a rule whose field the export does not carry reports insufficient data, never a pass. The import screen lists those rules before you import, so the limitation is visible while it can still change your choice of export.
- A BKMVDATA 1.31 file carries no allocation number, so the allocation rule reports insufficient data rather than flagging every invoice.
- A Hashavshevet MOVEIN export carries no VAT column, so the VAT rules report insufficient data rather than computing against zero.
- A CSV without a counterparty column still runs every rule that does not need one.