VAT automation in Ukraine: from invoice to КЕП submission

For a Ukrainian VAT payer, ПДВ is not a once-a-quarter chore. It is a monthly cycle with a hard deadline, an unforgiving reconciliation between what you charged and what you paid, and a filing that has to be signed and submitted to ДПС through an accredited channel. Get a supplier document wrong or lose one entirely, and the cost is direct: input VAT credit you cannot claim, or a credit you claimed and cannot defend.

This is exactly the kind of work an autonomous finance department is built to carry. FINMOZG runs the full ПДВ path — from the invoice and the bank statement to the signed submission — as a sequence of agent actions with a human approving the filing itself. This article walks through that path and the one failure mode that breaks most VAT cycles.

What the ПДВ obligation actually involves

A registered VAT payer charges ПДВ on taxable supplies and pays ПДВ on purchases. The return reports the difference, and the difference is what gets settled with the budget. Two sides drive every figure:

• Output VAT — the tax you charge customers on your sales. It flows from your issued invoices and is, in practice, the easier side: you control the documents because you create them.
• Input VAT — the tax you pay suppliers, which you can credit against output VAT. This is the fragile side. Every credit depends on a valid, matched supplier document, and that dependency is where most VAT problems start.

The return is the reconciliation of those two figures over the period, filed by the deadline and signed by an authorised person. Everything FINMOZG does is in service of making that reconciliation correct and defensible before anyone signs it.

The workflow, stage by stage

FINMOZG moves a ПДВ return through a fixed set of states, the same the rest of the Tax Engine uses, so the status is never ambiguous: Draft → Validated → Awaiting approval → Signed → Submitted → Accepted. Here is what happens at each step.

Import: bank and documents

The cycle begins with data, not data entry. The agents pull bank transactions and ingest supplier and sales documents — invoices, statements, expense records. Ukrainian bank connectivity is part of the Ukraine pack, with ПриватБанк and Монобанк supported via their APIs, so the bank side arrives without manual export and re-keying.

Classification and posting

The Bookkeeper Agent classifies each transaction, proposes the journal entry, and links it to its source document. Output VAT is recognised from sales, input VAT from matched purchases. Each posting carries a confidence score and an evidence link back to the document it came from, so nothing enters the ledger as an unexplained guess.

VAT ledger and the return draft

From the posted entries the Tax Agent assembles the ПДВ ledger — output VAT on one side, claimable input VAT on the other — and produces the return in Draft. At this point the numbers exist but are not yet trusted.

Validation against the posted ledger

This is the step that earns the trust. The agent validates the return against the actual posted ledger rather than against a separate spreadsheet that may have drifted. It checks that every claimed input VAT credit ties to a posted, documented purchase, that output VAT matches issued invoices, and that totals reconcile. A return that passes moves to Validated; anything that does not becomes a flagged exception for a human to resolve.

Approval and КЕП signing

A validated return goes to Awaiting approval. The authorised signer reviews the figures and the exceptions, then signs with their КЕП — the qualified electronic signature that gives the filing legal weight. The return is now Signed. Tax submission is a hard human boundary in FINMOZG: it never auto-executes, regardless of how confident the agents are.

Submission to ДПС and the response

Once signed, the agent submits the return to ДПС and records the outcome. The state becomes Submitted, and when the tax service confirms receipt it moves to Accepted. A rejection routes straight back to a human with the reason attached, so a failed filing is visible immediately rather than discovered later.

The failure mode that breaks VAT cycles

The single most common reason a Ukrainian VAT return is wrong is documents — specifically, missing or duplicated supplier documents on the input VAT side. A payment with no matching document means an input credit you cannot legitimately claim. A document counted twice means a credit you are not entitled to. Both are easy to miss in a manual close and expensive to unwind after submission.

FINMOZG treats this as a first-class check rather than an afterthought:

• Missing documents. When a bank payment or posted expense has no matching supplier document, the input VAT credit is held back and the item is flagged. The return will not silently claim a credit it cannot support.
• Duplicates. The Auditor and Compliance agents detect the same document or amount posted more than once and surface it before it inflates an input credit.
• Resolution before signing. Every exception is visible in the review queue while the return is still in Draft or Validated, so the person signing knows exactly what is and is not included.

The result is that the gap shows up before you file, not in a later query from ДПС.

The compliance calendar

ПДВ does not stand alone. A Ukrainian business is also tracking ЄСВ, ПДФО and військовий збір on their own schedules, each with its own deadline. FINMOZG keeps a compliance calendar that turns every filing deadline into a tracked task and prepares the draft ahead of time. The monthly ПДВ return is queued for review before it is due, not reconstructed in a rush on the last day. Missing a deadline becomes a deliberate omission you can see, not an accident.

Built for Ukrainian filing channels

Automating tax is only useful if it speaks the local channels. The Ukraine pack is built to integrate with the filing and signature infrastructure Ukrainian accountants already use — ДПС for submission, Дія for identity and signature, and the established reporting channels Медок and СОТА. Bank connectivity for ПриватБанк and Монобанк is supported via their APIs; the ДПС, Дія, Медок and СОТА integrations are integration-ready, so the workflow fits the tools your team relies on rather than replacing them.

Because ПДВ filings sit on top of a company's most sensitive financial data, the whole path runs under the same controls as the rest of the platform: confidence scores, evidence links, an immutable audit log of who signed and submitted what, and a zero-trust architecture. We cover the data side in security, and the broader Ukrainian setup in the Ukraine pack.

ПДВ in FINMOZG is not "AI filing your taxes." It is a VAT cycle that imports its own data, posts and reconciles it, validates the return against the real ledger, and stops for a human to sign with their КЕП before anything reaches ДПС — with every figure traceable to the document behind it.