Automatic sync with your accounting software

Almost every operator using VanaGreen works with an accountant or an external accounting firm, and until now nearly all of them had the same manual routine: someone exports the documents from the app, emails them or uploads them somewhere, and the accountant manually re-enters them into Nexus, SAGA, or WinMentor (the three accounting software packages most commonly used by Romanian firms). It's a step that creates no value on its own — it just moves the same data from one place to another, with error risk at every transcription.

What changed

VanaGreen's public API (/api/v1/public/), already used by partners to read documents, has been enriched with what was missing for a complete accounting integration: every collection or output record returned now also includes the actual material line items — waste code, net quantity, unit price, and line value — plus the partner's full identity (type, tax ID (CUI), name). A previously missing endpoint also appeared, for reading a single output record by ID, mirroring what already existed for collections.

Every API key can now be configured with a provider — Nexus, SAGA, WinMentor, or other — shown as a label in Settings → API Keys. It doesn't change which data flows through, but it makes clear at a glance which integration is tied to which key, useful especially for an operator running several accounting pipelines in parallel.

Confirmation, not just reading

The important new piece isn't just that the data is richer — it's that the integration now has a confirmation loop. When the accounting system reads a document through the API, it's automatically marked as "Read." But "read" doesn't mean "successfully processed" — a document can be read and still get rejected afterward by the accountant for some reason (a missing material code in their nomenclature, a format mismatch). That's why a separate confirmation endpoint was added, through which the accounting system explicitly reports back "I successfully processed document X" or flags an error — and that status becomes visible to the operator, not just to the accountant.

The rule is simple and intentional: once a document is confirmed, a later re-read doesn't downgrade it back to "read." That matters because an accounting system might read the same data more than once (retries, periodic syncs) without each read artificially resetting the document's actual status.

A new page for the operator

A "Accounting" page has appeared under Settings → Compliance, where the operator sees, for every finalized document, exactly what stage its sync is at — Unread, Read, Confirmed, or Error — filterable by document type, provider, and date range. In practice, the operator no longer has to ask the accountant "did you get last week's documents" — it's right there in the app.

A firm decision about personal data

On the partner identity side, individuals appear in the API with only their name — their CNP (Romanian national ID number) is never exposed, regardless of context or what the integration requests. It's a decision fixed in code, not just a documentation convention, precisely because a public API, once opened to an external partner, has to stay correct even if someone mistakenly asks for an extra field.

What this means in practice

For an operator with a high monthly document volume, the difference is the complete elimination of the manual handoff step to accounting — and, just as important, actual visibility that the documents made it where they needed to go, instead of just assuming "it was probably sent." The accountant confirms from their own system, not through a separate email, and any discrepancy shows up directly on the status page, not at month-end close.