NOVERA.Software
EN

05 · Statutory Compliance

Filings you can audit.

The VAT module produces the Slovak return and control statement, shows the ledger evidence behind every figure, and flags what does not tie. Submission stays with a person.

How the numbers are defended

Evidence is captured during calculation, so the transactions behind a box cannot disagree with the number printed above it.

The control statement is built from the return's own rows, so the two documents cannot drift apart. Empty sections stay visible at zero.

Both XML filings are written by hand to the exact conventions the portal expects, because no published schema exists. The specification used was six real accepted filings plus the previous system's writer, with the current output as the control.

A rejected return became two permanent rules: which figures negate on which transaction types, and that rounding happens before derivation. Both now live in one place.

The module at a glance

  • VAT return (DPDPH): declaration, box grid, evidence and control statement, shown as four faces
  • Control statement (KV DPH): sectioned from each ledger line's own attribute
  • Two XML exports: byte conventions proven against accepted filings
  • Supporting listings: grouped by section at line level, so a split invoice appears under both
  • Printed forms: A4 and A3 landscape, in statutory section order
  • One write in the module: the VAT code editor, inside a transaction that rolls back unless exactly one row moves. It is refused once a return is filed.

Platform description

Statutory compliance

The Slovak VAT module produces the return and the control statement, shows the ledger evidence behind every figure and flags what does not tie. It stops short of submission on purpose: a person uploads the completed file to the tax portal. The system draws the same boundary around its AI.

The return is presented as a four-face deck: the declaration, the box grid, the evidence and the control statement.

  • The box engine reproduces seventeen filter sets from the original system and has no database, clock or culture dependency.
  • It records its evidence as it computes. Because the evidence is captured during the calculation, the drawer of transactions behind a box cannot disagree with the number printed above it.
  • Rate codes change by year, derived totals follow the statutory order, and every box is rounded to two decimal places before anything is derived from it.

The control statement is built from the return's own rows, with no second query, so the two documents cannot drift apart. Sections are mapped from each ledger line's own analysis attribute, and empty sections stay visible at zero.

Both filings are written as XML by hand, because the exact conventions the portal expects are not published as a schema anywhere.

  • An unused box is an empty element, never a zero.
  • The control statement's root element is derived from the period.
  • Each section carries its own attribute set.

The specification was six real accepted filings and the original system's own writer, with the current build's output as a control. A rejected return produced two permanent rules, now kept in one place: which figures negate on which transaction types, and that rounding happens before derivation.

Around the two filings sit the supporting listings, a printed form for each document and a VAT code editor. The listings are grouped by control statement section at line level, so an invoice spanning two sections appears under both.

The editor is the only write in the entire module. It moves one ledger line's analysis or section code inside a transaction that rolls back unless exactly one row changes, and it refuses outright once the period's return has been filed.