SAGA accounting export — now with XML, not just .dbf, tested with a real accountant

We launched the first version of the SAGA export — SAGA being the accounting software used by many small and mid-sized companies in Romania — in .dbf format, for individuals, waste items, intakes, and outflows. A few days later, one client's accountant tried to import it. SAGA didn't throw any error. It simply didn't pick anything up.

That's what a real production bug often looks like: not an error message, but a silence that lets you believe it worked.

What actually happened

The .dbf format we built initially was our own interpretation, based on general dBase format documentation — not officially documented by SAGA for this exact purpose. When we looked directly at the official SAGA manual, we found the answer: the data import page explicitly documents only the XML format, not .dbf. That explains the silent failure — SAGA probably didn't even recognize the file structure as valid input for that screen.

We built the XML exports from scratch, for individuals, companies, and waste items, alongside the existing .dbf — we kept it active until we had a real confirmation of a successful import, so we wouldn't lose the only working option if the new format also had issues.

Actually tested, step by step, with the accountant

This is where live verification mattered most, not assumption. We went through every export together with the accountant, with real screenshots from SAGA:

• For individuals, the Cod_fiscal field accepts the CNP (Romanian personal ID number) directly — no need to invent a separate identifier.
• SAGA assigns its own sequential internal codes to every new entry — if we had forced our own identifier into that field, we would have risked the exact same silent failure as with .dbf. Our internal code instead goes into a separate field, dedicated to stable matching on later re-imports.
• The waste item export was fully rejected on import if the item type was missing — a clear message, "select an item type," but one that blocked the entire file, not just that line. Item type is a configurable nomenclature that differs from one company to another in SAGA, so it couldn't be hardcoded generically — we added a per-client configuration field, editable through a form protected against accidental changes.
• On the intake export, another import failed completely with the error "the submitted county code is invalid" — because we were sending the operator's free-text entry ("București") instead of the standard code SAGA expects. We reused the same county normalization logic already built for the e-Factura (Romania's e-invoicing system) integration.

The fix that mattered most to the client

The most important fix came directly from Stefan, after he saw the result in SAGA: the document number showing up on intake invoices was the app's internal tracking code (something like COL-26-0043), not the legal borderou (waste transfer note) number (something like BRD000013) that the accountant expected and looks for during reconciliation.

The difference looks small, but it matters enormously for anyone doing accounting — an accounting document has to carry the legal, officially recognized number, not an internal app identifier. The same confusion existed, undiscovered until then, in the old .dbf export too. We fixed it in both formats and added a dedicated test, so it doesn't quietly come back with a future change.

Why it matters for an operator

An accounting export that doesn't work on import isn't a visible problem right away — it shows up only when the accountant actually tries to use it, often at month-end, under time pressure. Live verification with a real accountant, on real SAGA, not assumptions about how the format should look, is the difference between an export that "looks correct" and one that actually works with your accounting.

If you work with SAGA, the XML export is now explicitly recommended from the reports page — .dbf remains available, but XML is the officially documented format, tested directly against a real import case.