Electronic invoice automation does not begin with a “send” button. It begins with a question: where does the data come from, and what must happen after the document is issued? When an order already exists in a sales system, the service scope is fixed in a contract, and customer details are held in accounting software, entering the same information again manually becomes an unnecessary link. It puts pressure on accounting and creates discrepancies between the order, invoice, payment, and actual fulfilment.
For companies in Serbia, an important part of this process is the Electronic Invoicing System, SEF. It is a state system of the Republic of Serbia, not a VMTech product and not evidence of any institutional partnership. Automation has a different purpose: to establish a controlled data path from an order or calculation to an electronic invoice, its status, accounting records, and the next action within the company.
A properly designed process does not remove people from every operation. Standard documents can be handled under agreed rules, while rejections, corrections, partial payments, and disputed situations require a responsible employee. The goal is therefore not “full autonomy,” but a predictable flow: routine operations proceed without repeated data entry, while exceptions reach the appropriate specialist on time.
Why manual invoicing affects more than accounting
Issuing an invoice may appear to be a local accounting task. In practice, its data arises earlier: when an order is placed, a commercial offer is approved, a contract is signed, the scope of a service is calculated, or goods are prepared for dispatch. If these details are transferred manually, the accountant has to enter customer information, line items, quantities, values, taxes, dates, and internal numbers again.
The issue is not limited to staff time. One order may have a number in the sales system, another identifier in the accounting application, and a separate reference in a bank statement. An employee must determine whether all of these records concern the same transaction. Similar amounts, repeat orders, or multiple invoices for one customer increase the likelihood of an incorrect match.
Once the document is sent, a second manual cycle begins. Someone checks its status, reports the result to the manager, clarifies details with accounting, and passes information to the operations team. If confirmation of actual payment arrives separately, it must again be linked to the invoice and order. As long as this chain depends on messages, spreadsheets, and employee memory, there is no single complete view.
What should be automated is not the isolated action of creating an invoice, but the entire controlled route: the data source, validation, document issue, status monitoring, payment confirmation, and the permitted next action.
From order to electronic invoice
The starting point may be a goods order, subscription, completed-stage certificate, monthly calculation, service contract, or sale confirmed by a manager. Before a document is created, the system must identify the customer, basis, line items, amount, currency, tax parameters, date, and internal owner. These rules cannot be guessed during development: they must be agreed by the business, accounting, and technical teams.
The next step is a completeness check. If a required detail is missing, the customer identifier does not match, or no rule exists for a particular transaction type, the document must not silently continue through the flow. It is moved to an exception queue with a clear reason and an assigned owner. This is safer than automatically issuing a formally completed but incorrect invoice.
After successful validation, an electronic document is created and sent through the channel intended for it. SEF supports work with electronic invoices and their statuses within Serbia’s state framework. A company’s specific obligations, tax categories, and document rules depend on the nature of the transaction and current requirements. They must be confirmed with a qualified accountant or legal adviser.
The sending result must return to the company workflow. An employee should not have to search for a document in several windows when its internal number, order number, and current status are already linked in one record. Automation must also preserve the source data, operation time, and change history so that the sequence of actions can be reconstructed.
Direct connection or controlled file exchange
The way data is transferred to accounting software depends on the system’s actual capabilities and configuration. It cannot be assumed in advance that every product used by a company supports a direct connection or will automatically post a received document. This has to be checked separately against documentation, available features, software version, and accounting procedures.
When controlled import and export is enough
File exchange can be a sensible solution when there are few documents, operations are processed in batches, and the accounting application does not provide a reliable direct connection. It must not be an incidental movement of files between folders, but an established procedure. That procedure should include format validation, export logging, protection against repeat import, an error report, and reconciliation of the result.
This approach retains control and can remove repeated data entry without a complex rebuilding of every system. It is particularly suitable at an initial stage, when a company wants to test process rules and the quality of source data. Its limitation is clear: exchange occurs at set intervals, and some actions remain with an employee.
When a direct connection is justified
A direct option becomes more useful with a regular document flow, a need to receive status changes quickly, or a need to start subsequent operations without waiting for a batch upload. It can also help when order, customer, and fulfilment data are already spread across several systems and need to remain consistent.
However, a direct connection does not fix a poor process by itself. Without a unified numbering rule, an owner for corrections, and a procedure for handling duplicates, automation will only spread an error faster. VMTech first reviews the specific systems and work logic, then determines the appropriate exchange method. This class of work is described in more detail on the page about CRM, ERP, and accounting integration.
Document status and actual payment are different events
One of the most dangerous project mistakes is to assume that electronic invoice status always confirms receipt of money. Document status shows what has happened to the invoice itself: it was created, sent, accepted, rejected, cancelled, or changed within available operations. Payment is a cash movement and must come from a source suitable for the particular company.
These events may occur in a different order and with different delays. A customer may accept an invoice but pay later. A payment may arrive partially, as one amount for several documents, or with a reference that does not allow a reliable automatic match. The reverse is also possible: money has already arrived, while document status does not yet show the action expected from the recipient.
The process model therefore needs separate fields and separate rules for invoice status and payment status. The interface may show them together, but must not merge them. The next business action is triggered only by the event the company actually requires: for example, confirmed receipt of the full amount, manual approval by a finance employee, or several conditions met at the same time.
What may happen after confirmed payment
Confirmed payment is valuable not as a mark in a spreadsheet, but as grounds for the next controlled step. For a service, this may mean activating access, opening a paid period, assigning a performer, or notifying a team. For goods, it may mean authorising picking, preparing documents, transferring the order for dispatch, or informing the responsible employee.
The action selected depends on risk. A manager may be notified automatically under a relatively broad set of conditions. Activating an expensive service, shipping goods, or granting access to sensitive data should happen only after strict checks of the amount, currency, customer, payment reference, and link to a specific invoice. Some operations may reasonably retain manual approval even where the match is correct.
VMTech applies this principle in its own projects: electronic invoicing and payment confirmation are treated as parts of a longer business process. The confirmation source is determined by the architecture of the specific solution. It is not automatically attributed to SEF and is not treated as universal for every company.
Linking the order, invoice, customer, and payment
Reliable automation is built on stable identifiers. An order, customer, invoice, and payment may have different numbers, but the system must hold explicit links between them. Matching by amount alone is insufficient: identical amounts occur regularly, while partial or combined payment breaks that logic.
For every transaction, it is useful to define one primary internal identifier and a set of additional attributes. They may include the order number, document number, customer details, amount, currency, date, and payment reference. The higher the risk of an incorrect activation, the more independent conditions should match before the flow continues automatically.
A separate rule is required for repeated processing. If the same message, file, or document arrives a second time, the system must recognise the duplicate and must not create another invoice, repeated posting, or second activation. It does this by preserving the operation identifier, its result, and a marker for the completed action.
Data links also matter for analytics. The company can see not just a list of issued invoices, but the route of a specific order: when it was confirmed, which document was created, how its status changed, when payment was established, and which action followed. General principles for eliminating repeated data transfer are also covered in an article on linking CRM, ERP, orders, and accounting.
Exceptions that cannot be left until later
The main flow usually looks simple, but solution quality is determined by its behaviour in non-standard situations. Before launch, the following cases should at least be documented in writing:
- Document rejection. Who receives the notification, where is the reason recorded, and can a corrected version be sent again?
- Reversal or correction. Which subsequent actions must stop, and who confirms the change?
- Partial payment. Does it permit fulfilment, or is the full amount required?
- Overpayment or combined payment. Can the system match it unambiguously, or is the decision passed to accounting?
- Duplicate. How are repeated document creation and repeated service activation or dispatch prevented?
- Incomplete data. Which employee completes the details, and how does the task return to the main flow?
- Temporary system unavailability. Where is the operation retained, how many times is it retried, and when is intervention needed?
- Manual change. Who may correct information, and how is this reflected in the history?
Every exception needs an owner, an acceptable response time, and an understandable final state. A record saying “exchange error” is not enough: the employee needs the order number, document type, reason for the stop, and a safe action that can be performed.
Security, access rights, and the action log
A financial process involves company details, amounts, documents, and employee authority. Access should be granted by role: a manager does not necessarily need authority to make accounting corrections, and a technical specialist should not make a financial decision. Changing a critical rule or manually starting a risky operation may require an additional confirmation.
The action log should answer practical questions: which data was used, who changed a record, when a document was created or corrected, why an operation stopped, and on what basis it continued. This supports error analysis and prevents history from being replaced with only the latest value.
Protection against silent failures is equally important. If one system is temporarily unavailable, an operation must not disappear or be treated as complete. It is retained with its current status, retried under an established rule, or passed to a responsible employee. Monitoring should detect not only an explicit error, but also a situation in which an expected event has not occurred for too long.
This material explains how to organise a digital process and is not accounting, tax, or legal advice. Applicable obligations, document categories, and accounting rules must be checked for the specific company and transaction.
Implementation stages without a risky “big launch”
It is safer to introduce automated invoicing in stages. Trying to cover every sales type, document, branch, and exception at once makes validation harder and makes the causes of errors more difficult to find.
- Map the current process. Record data sources, manual actions, systems in use, employee roles, and decision points.
- Check the systems. Determine which methods of sending and receiving data are actually available in installed software versions.
- Describe the rules. Define document types, required fields, identifiers, issue conditions, payment rules, and exception owners.
- Pilot one flow. Select a limited, understandable scenario, such as one service type or one order group.
- Run parallel control. Compare automated-route results with the existing procedure and classify detected discrepancies.
- Acceptance and monitoring. Check the action log, duplicates, retries, access rights, and stop notifications.
- Expand gradually. Add new document types and subsequent actions only after the previous stage works consistently.
It is not possible to state a project’s time frame and cost correctly without assessing the systems, document volume, and company rules. Even identical accounting applications may be configured differently, and the same invoice type may start different actions in two organisations.
When automation is unsuitable or should be postponed
A direct connection may not justify the investment where a company issues only a few non-standard invoices per month and each document requires professional judgement. In that situation, controlled import, a template, and a strict review procedure may provide a more reasonable balance of cost and risk.
The project should also be postponed if the customer directory is inconsistent, calculation rules exist only in one employee’s memory, or order numbers are not retained in the accounting environment. Data and responsibility should be stabilised first. Otherwise, the digital flow will regularly stop or issue documents that require manual correction.
Automation should not initiate irreversible action when payment is ambiguous. If an amount cannot confidently be linked to an order, the safe outcome is a task for a finance employee, not automatic activation or dispatch. A controlled stop is part of a good solution, not a shortcoming.
What to prepare for an engineering assessment
Before discussing implementation, prepare a short description of the current process. State where an order is created, who confirms the composition and cost, which accounting application is used, which electronic invoice types are involved, and how employees currently learn that a document status has changed.
Describe payment separately: where confirmation comes from, whether partial and combined payments are possible, which data is used for matching, and what action must happen next. It is useful to attach anonymised field examples and list exceptions that the team encounters in actual work.
This makes it possible to assess whether controlled file exchange is sufficient, whether a direct connection is possible, and which checks are needed before the next business action starts. Such an assessment automates the repeatable part of the process without removing human responsibility where a decision needs accounting or operational judgement.
