Automated invoicing: a controlled workflow from order to confirmation
When can invoicing start automatically, what needs validation, and how should invoicing-provider and Hungarian tax-reporting states be tracked?
AT A GLANCE
Automated invoicing turns a verified business event, such as a completed order, into an invoice-creation request for the invoicing system. The workflow must validate customer, line-item, performance-date, and tax data before issue, then track invoice creation and Hungarian Online Invoice reporting as separate states. The design below is illustrative, not tax or accounting advice and not a client project.
- Use one explicit, repeatable business event as the trigger.
- The invoicing system and NAV processing response are separate checkpoints.
- After a timeout, query state instead of blindly creating another invoice.
What should trigger automated invoicing?
Use a business event that is explicit and traceable, such as approved performance, completed delivery, or another state that matches the actual agreement. A button click or payment-provider notification does not always prove that every invoicing condition is satisfied. Record which system is authoritative for the event, who may change it, and when it becomes final.
Have an accountant or tax adviser confirm the actual issue date, required data, and tax treatment for the business transaction. The technical workflow should execute an approved rule; it should not guess the performance date, tax rate, or party to be invoiced.
Validate a complete data package before issue
The request to the invoicing system should carry a durable case or order ID, customer identifier, name and address, tax number where required, performance and issue dates, currency, payment terms, line items, quantities, unit prices, discounts, tax treatment, and totals. Required fields and rules depend on the transaction, so the field map needs an owner and version.
Recalculate totals and stop on an unknown customer or product, contradictory currency, date, or tax configuration. Invalid data should not be sent to an external provider on the assumption that it will reject the request. Store validation results with the case so the same checks can run again after correction.
Treat the invoicing-provider response as durable state
Give every issue request an idempotency key or another stable identifier that prevents one business event from creating two invoices. From a successful response, retain the invoice identifier and number, creation time, and provider status. A document URL alone is insufficient when the originating request and data cannot be reconstructed later.
After a timeout or broken connection, query provider state first. “No response received” is not the same as “no invoice created”. Retry automatically only when the provider contract and identifiers guarantee duplicate protection; otherwise send the case for human review.
Invoice issue and Hungarian tax reporting are separate states
NAV guidance says invoice data reporting is completed through the Online Invoice system, while machine-to-machine access uses its own technical user and processing feedback. Track separately whether the invoice exists in the invoicing system, data was submitted, NAV accepted the transaction, and processing completed successfully. An HTTP response or submission ID is not necessarily the end of the workflow.
NAV’s official interface materials document test and production environments, schemas, and queryable transaction states. Monitor processing errors and persistent warnings, assign an owner, and repeat reporting in a controlled way after correction. Determine the actual legal obligation from current NAV guidance and professional advice.
Corrections, cancellation, and manual intervention
Do not overwrite an issued invoice as if it were still a draft. Correction or cancellation should use the invoicing system’s supported operation and the approved accounting process, with a reference to the original document. Keep the original invoice, reason, decision owner, and new document state visible in the internal case.
After manual intervention, reconcile state between systems. If someone corrects data directly in the invoicing system, the automation must not repeat the operation from stale internal data. Return synchronisation and logged discrepancy handling matter as much as the first automated issue.
Pilot with real acceptance criteria
Include a normal order, missing customer data, currency mismatch, discount, different tax treatments, an already processed event, timeout, provider error, and NAV processing error. Define the expected invoice and case state for every test and whether work may continue automatically or needs a person.
Measure successful issues, duplicate warnings, data corrections, uncertain outcomes, provider and NAV errors, and human review effort separately. This illustrative pilot is not a verified saving. It shows whether the workflow is controllable, failures are traceable, and operation can be handed over safely.
Sources and further reading
- Az Online Számla rendszer használataNemzeti Adó- és Vámhivatal · Checked: 2026-10-31
- Online Számla rendszer — hivatalos interfészanyagokNemzeti Adó- és Vámhivatal · Checked: 2026-10-31
- Az online számlaadat-szolgáltatás gyakori hibáiNemzeti Adó- és Vámhivatal · Checked: 2026-10-31
Related questions
When can an invoice be issued automatically?
When an approved, traceable business event and a complete, validated invoice data set are available. An accountant or tax adviser should confirm the issue date, required data, and tax treatment for the transaction; the automation should execute that approved rule.
Are automated invoicing and NAV reporting the same process?
No. The invoicing system creates the invoice, while the Online Invoice system processes the required reporting. Track the invoice identifier and state, reporting transaction, and NAV success or error response separately.
Borbély Kristóf
The developer behind Kriside, writing practical guides about web systems, automation, and AI solutions.