SAGA, WinMENTOR and JPK_V7M exports

Your accountant works in SAGA, WinMENTOR or Comarch Optima, and Druma has no live link into any of them. It hands over files: a monthly ZIP for SAGA, text files for WinMENTOR, and the sales side of the Polish JPK_V7M(3). The JPK file follows the Ministry of Finance JPK schema (the XSD published on 19 December 2025), and the code that writes it is tested against that schema. Druma has not tested the import into Comarch Optima.

Romania: SAGA and WinMENTOR

Early in November the accountant asks for October. The SAGA export is one ZIP for the month with the five files SAGA imports (clients, articles, sales, purchases and payments) and a README. A client gets a SAGA code the first time it is exported and keeps it, so the same shipper does not appear twice in the ledger after the next month's import.

WinMENTOR gets pipe-delimited text files for sales and payments, in the Windows-1252 encoding it reads.

A proforma is not a tax document, so it stays out of every export. Only the invoice it is converted into goes to the accountant.

If your accountant uses another package, an export profile builds the file their import expects. A typical one is semicolon-separated, with comma decimals, day-month-year dates and Windows-1252 encoding; the profile also sets which columns appear and in what order. A nominal code map turns a VAT rate, an account type, a client or a service into the account code your ledger uses, so the accountant stops recoding lines by hand. The first rows show in a preview before the profile is saved.

Poland: JPK_V7M(3)

JPK_V7M(3) is the monthly Polish VAT records file, due by the 25th of the following month. Druma builds the sales side.

The schema requires one KSeF marker on every sales row. An invoice accepted in KSeF production carries its KSeF number. An invoice issued outside KSeF is marked BFK. OFF is only for an invoice issued offline that has no number yet; once the number has arrived, exporting the month again writes the number instead of OFF.

Any other invoice sent to KSeF that has no valid number stops the export, and the message names the invoice. The same goes for an invoice sent with "Send without KSeF". The file can be built once those invoices have their numbers.

Euro invoices are converted at the National Bank of Poland rate of the last working day before the tax point. The rate, its date and its NBP table number are stored with the invoice, so when October is exported again in December the same PLN figure comes back.

Take an invoice of EUR 1,500 from a Poznań haulier to a German client for a load to Hamburg. The service is taxed in Germany, so it goes into both K_11 and K_12, as the schema requires, with no Polish VAT. If the NBP rate stored on the invoice is 4.2700, both boxes carry PLN 6,405.00. Have your accountant confirm the VAT treatment of each kind of invoice you issue before the first filing; the boxes follow from that choice.

Two settings cannot be derived from your data and block the export until someone fills them in: the tax office code and the contact email for the filing.

There are three ways to hand the file over. Download it. Let Druma email the previous month to the bookkeeper on a day of the month you choose. Or let the accountant's side pull it: with an API key, a call to Druma's public API returns the XML for the previous month. Optima has no interface Druma can call from outside, so an automatic pull has to start at the accountant's end.