Financial Document Workflows: From Invoice to Confirmed Payment
An 'approved' label helps the finance team only when everyone knows what was approved. It might mean permission to incur a cost, the outcome of a document check or authorisation for the next step in preparing a payment. Combine those events into a single status and staff will have to piece together the transaction's progress from correspondence, the accounting system and bank information.
Electronic document management (EDM) should connect documents and people's actions with records in other systems. That requires separate answers: what was received, what was checked, what was decided and what supports the payment status. These are the transitions to design and test when automating the process.
Article updated on 24 September 2026. Legal and technical sources were checked as of that date.
Establish which transaction the documents describe
Consider a hypothetical delivery of consumable materials, with payment due after acceptance. The organisation has received the supplier's invoice and goods receipt documents, but the person handling acceptance has reported a quantity discrepancy. This is an illustrative scenario. Advance payments, partial deliveries and returns may need a different workflow.
Article 1 of Ukrainian Law No. 996-XIV defines a primary accounting document as containing information about a business transaction. Article 9 makes such documents the basis for recording transactions in the accounts and sets requirements for their preparation. Paper and electronic forms are allowed under the applicable conditions. The label 'invoice' alone therefore does not establish whether a document is sufficient for a particular accounting entry.
Start by linking the invoice to the order or contract and the supporting documents needed. For our example, identify these details:
- Supplier. Who issued the document and which supplier the order relates to.
- Materials supplied. What materials were expected and what actually arrived.
- Quantity and value. Units of measure, prices, amounts and the terms used to calculate them.
- Supporting basis. The contract, order or other document against which the transaction is checked.
This is a working list for our example, not a universal list of required details for primary accounting documents. Check the requirements for the particular document separately. Also make clear which information came from the supplier and which records your organisation's own acceptance of the goods.
Give each status a clear meaning
In our scenario, the invoiced quantity differs from the quantity accepted. Establish why: an incomplete delivery, different units of measure, an error in a document or another cause. An 'uploaded' label cannot answer that question. Keep the discrepancy visible and assign it to the person responsible for resolving it.
Microsoft's Dynamics 365 Finance documentation describes two-way matching of invoice prices against a purchase order. Three-way matching adds a quantity check against goods receipts. Policies and tolerances are configurable. This is a feature of a particular ERP system, not a standard capability of every document management system or a legal requirement to follow that exact approach.
Agree on what status labels mean so that everyone reads the process in the same way. The following is a proposal for discussion, not a list of built-in product statuses:
| Label | What to record | What it does not prove |
|---|---|---|
| Received | Where the materials came from and what was received | That all data is correct |
| Checked | What was checked and which questions remain unresolved | Permission to take any further action |
| Approved | Who authorised a specific action and under what conditions | That the payment was executed |
| Payment confirmed | The transaction, amount and supporting record | That all other obligations have been settled |
Do not hide open questions behind a general 'checked' label. If the quantity matches but the price still needs clarification, the next person should be able to see that. When corrected documents arrive, review which earlier conclusions still hold and which need revisiting.
Approve a specific action, not the file as a whole
For this delivery, assign the checks to clear roles. Who confirms acceptance? Who resolves the discrepancy with the supplier? Who assesses the documents for accounting, and who authorises payment preparation? The organisation defines these roles under its own rules; they do not necessarily require separate job positions.
Under Part 6 of Article 18 of Ukrainian Law No. 2155-VIII, a qualified electronic signature (QES) has the same legal effect as a handwritten signature, with a presumption of equivalence. That provision concerns the signature. A verification result alone does not establish how much material was accepted or whether a payment was executed.
When sending an invoice for approval, specify the action required and show any discrepancies. For example, ask the approver to review the documents once the quantity has been clarified and decide whether payment preparation can proceed. If a question remains open, identify who needs to answer it and what information is missing.
Changes after approval also need attention. Do not silently replace an approved version. Keep the versions linked and determine whether your procedure requires another review. The receiving system can then get data with a clear basis, rather than simply the most recently uploaded file.
Check what the accounting system actually accepted
When data enters an enterprise resource planning (ERP) system, successful delivery and readiness for accounting may have different outcomes. A request might be accepted for processing while the required record has not yet been created, or an error may be returned. Allow for these cases when specifying the data exchange.
Dynamics 365 Finance has separate settings for submitting imported invoices to an approval workflow and matching their lines against goods receipts. Microsoft also describes running these steps in the background. Importing data does not establish that every required check has passed, although some checks may take place during import.
- Link the records. Connect the document ID in EDM to its record in ERP.
- Check the transferred data. Compare the party, amount, currency, quantity and required references.
- Capture the result. Keep the system's response, the time and any reason for rejection.
- Test retries. Establish what happened to the previous request and agree on a retry method that avoids creating a duplicate.
Megapolis.DocNet's developer describes document records, activity logging and an open API for integration with ERP and accounting systems. An API provides a basis for data exchange, but the fields, responses and error handling need to be agreed for each implementation.
Test how repeats are handled by sending the same data again, then separately simulating a lost response. Decide how to find a record that has already been accepted and who resolves an uncertain result. A document number alone, without the supplier and transaction context, may not be enough for your matching rule.
Confirm payment for a specific transaction
Microsoft's bank reconciliation documentation describes importing and validating statements, then matching their lines against bank transactions recorded in the accounts. This is a Dynamics 365 Finance process, not a Ukrainian banking rule. The useful principle for our scenario is to tie payment status to a specific supporting record.
Define in advance what the source confirms: a debit, a returned payment or another event. Keep the amount, the link to the delivery and the time of the update. An overall reconciliation result does not replace checking the particular invoice. A debit should not automatically be described as confirmation that the beneficiary received the funds.
Prepare one delivery as a test case to discuss with IQusion: the documents, a discrepancy, approval, data exchange with ERP and the payment confirmation needed. Work through each role and note any missing response, link between records or assigned responsibility. That gives the automation project a concrete task to address.
Frequently asked questions
Do we need the same documents for every expense?
The documents and workflow depend on the transaction and the applicable requirements. A delivery, advance payment, service or return may need different checks. The article's example does not replace deciding what your own process requires.
What if ERP does not respond after we send the data?
Do not assume the data was rejected. Check the previous request and the linked record under your integration's rules. Assign someone to handle uncertain results and test retries with test data before launch.
How can we measure the benefits without promising a percentage?
Choose your own measures: time from receipt to completion of a particular check, documents sent back because of discrepancies, manual data transfers and records with an unclear status. Compare the same types of transaction over the same process stages, accounting for exceptions separately.
Sources
- Law of Ukraine 'On Accounting and Financial Reporting in Ukraine' No. 996-XIV
- Law of Ukraine 'On Electronic Identification and Electronic Trust Services' No. 2155-VIII
- Megapolis.DocNet features and functionality
- Accounts payable invoice matching overview
- Submit invoices to the workflow system and match product receipt lines
- Reconcile bank statements by using advanced bank reconciliation
