Electronic invoicing automation does not start with a “send” button. It starts with a practical 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 scope of a service is recorded in a contract, and customer details are held in accounting software, entering the same information again manually becomes an unnecessary link in the process. It burdens accounting and creates discrepancies between the order, invoice, payment and actual fulfilment.
For companies in Serbia, the System of Electronic Invoices, SEF, is an important part of this workflow. 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: creating a controlled data path from an order or calculation to the electronic invoice, its status, accounting records and the next action within the company.
A well-designed process does not remove people from every operation. Standard documents can be processed under agreed rules, while deviations, corrections, partial payments and disputed situations require a responsible employee. The goal is therefore not “complete autonomy”, but a predictable flow in which routine operations proceed without duplicate entry and exceptions reach the appropriate specialist in time.
In Serbian business practice, this task is often described as eFaktura integracija. The term may cover connecting SEF with a CRM, ERP, accounting application, order database or a company’s own application. The scope is defined not by the label of the task, but by the document’s actual route: where the transaction starts, who checks the data, where the result is recorded and which next action may be taken.
What eFaktura integration with SEF means
eFaktura integration is a managed exchange between SEF and a company’s internal systems. SEF provides connection through a programmatic interface; before development, the current procedure for access, key generation and storage, as well as the current technical documentation, must be reviewed. The existence of an API alone does not establish compatibility with a particular accounting application. Its version, configuration and available exchange methods require separate assessment.
The project boundary can vary. In one case, a system only prepares and submits data for a document. In another, it also records the technical processing result, links it to an order and creates a task for the responsible employee. Available statuses and actions must not be assumed in advance: they are checked against current SEF documentation and matched to the company’s business rules before the scenario is designed.
The item to automate is not a single button, but a controlled route: the data source, validation of mandatory fields, document creation, recording of the result, separate payment confirmation and the permitted next action.
Why manual invoicing affects more than accounting
Issuing an invoice can look like a local accounting task. In reality, its data arises much earlier: when an order is placed, a commercial offer is approved, a contract is signed, a service volume is calculated or goods are prepared for shipment. If these details are transferred manually, the accountant must re-enter customer details, line items, quantities, amounts, taxes, dates and internal numbers.
The issue is not limited to working time. One order may have a number in the sales system, a different identifier in accounting and another reference in a bank statement. An employee then has to determine whether all records concern the same transaction. Similar amounts, repeat orders or several invoices for one customer make an incorrect match more likely.
After the document is sent, a second cycle of manual work begins. Someone checks its status, communicates the result to the manager, clarifies information with accounting and passes it to operations. 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 employees’ memory, there is no single picture of the operation.
Integration must therefore answer more than “how do we transmit an invoice?” It should also answer “where did the values come from?”, “who corrects an error?” and “what counts as completion of the transaction?” This removes repetitive manual transfer while retaining accounting and operational control.
From an order to an electronic invoice
The starting point may be a product order, subscription, document confirming completion of a project stage, monthly calculation, service contract or manager-confirmed sale. Before a document is created, the system must determine the customer, basis, line items, amount, currency, tax parameters, date and internal responsible person. These rules should not be guessed during development: they are agreed by the business, accounting and technical teams.
The next step is completeness validation. If a mandatory detail is missing, a customer identifier does not match or no rule exists for a particular transaction type, the document must not silently continue through the process. It is moved to an exception queue with a clear reason and assigned owner. This is safer than automatically issuing an invoice that is formally filled in but incorrect.
Once checked, prepared data is transmitted by the applicable method. The technical result should be stored alongside the internal order number and document identifier. The team confirms which responses, statuses and actions are available in SEF from current documentation during design, rather than fixing the scenario around an outdated list.
A company’s specific obligations, document types, tax categories and formatting rules depend on the transaction and applicable requirements. They should be confirmed by a qualified accountant or legal adviser. The technical team implements the agreed logic; it does not replace professional interpretation of accounting rules.
Data that needs to be matched
The minimum field set depends on the transaction type. A data map will usually include an internal order number, customer identifier, line items, amounts, currency, dates and a responsible person. Tax and accounting fields are approved by the client’s specialist; a developer should not select their values independently.
For every field, record its source, format, mandatory status and behaviour in case of an error. This mapping table reveals discrepancies: a customer may be recorded under several names, currency may not be passed explicitly, or an order number may be absent from the accounting environment. These issues are best resolved before exchange is connected.
SEF API integration or file exchange
The way data is transferred to accounting software depends on its actual capabilities and settings. It cannot be claimed in advance that every product used by a company supports a direct connection or will automatically post a received document. This is checked separately through documentation, available functions, software version and accounting procedures.
When controlled import and export is suitable
File exchange can be a reasonable option when there are few documents, operations are performed in batches, and the accounting application does not offer a reliable direct connection. It must not be an ad hoc movement of files between folders, but an established procedure with format validation, export registration, protection against repeat loading, error reporting and result reconciliation.
This approach preserves control and can remove duplicate entry without a complex restructuring of every system. It is especially suitable at an initial stage, when a company wants to test its process rules and source-data quality. Its limitation is clear: exchange happens at a defined interval and some actions remain with an employee.
When to assess a direct connection
A direct connection is worth assessing for a regular document flow, where data from several systems must be aligned, or where a technical processing result needs to return to a CRM or ERP. Its feasibility and scope can be confirmed only after reviewing the specific software environment and current access requirements.
A direct connection does not, by itself, correct a poor process. If there is no common numbering rule, no owner for corrections and no procedure for duplicates, automation will only spread an error faster. VMTech first reviews the actual systems and working logic, then identifies an appropriate exchange method. This type of work is described in more detail on the page about CRM, ERP and accounting-system integration.
An engineering assessment requires software versions, available connection methods, anonymised field examples, access restrictions and expected operation frequency. VMTech can connect systems through APIs, webhooks, FTP and databases, but the applicability of a given option is determined after reviewing the client’s infrastructure.
Invoice status and actual payment are different events
The status of an electronic document must not automatically be treated as confirmation that funds have been received. It concerns processing of the document in the relevant environment, while payment concerns movement of money. The exact technical statuses and available operations are checked against current SEF documentation before implementation.
These events may occur in a different order and with different delays. A customer may process an invoice and pay later. A payment may arrive partially, as one amount for several documents, or with a payment purpose that does not permit a reliable automatic match.
The process model therefore needs separate fields and rules for invoice status and payment status. An interface may display them together, but must not merge them. The next business action starts only from the event actually required by the company: for example, confirmed receipt of the full amount, manual approval by a finance employee, or several conditions being met together.
Linking the order, invoice, customer and payment
Reliable automation is based on stable identifiers. Orders, customers, invoices and payments may all have different numbers, but the system must retain explicit links between them. Matching by amount alone is insufficient: equal amounts occur regularly, and partial or combined payments break that logic.
For every transaction, it is useful to define a primary internal identifier and a set of additional attributes. These can include the order number, document number, customer details, amount, currency, date and payment purpose. The higher the risk of an incorrect activation, the more independent conditions should match before the process continues automatically.
A separate rule is needed for repeated processing. If the same message, file or document arrives a second time, the system should recognise the duplicate and avoid creating a new invoice, repeat posting or second activation. This requires preserving the transaction identifier, its result and a marker for the completed action.
Data continuity makes it possible to see the route from the original order to the document and later action. General principles for removing repeated transfer are explained in the article about connecting CRM, ERP, orders and accounting.
What happens after confirmed payment
Confirmed payment matters not as a mark in a spreadsheet, but as the basis for the next controlled step. For a service, that may mean activating access, opening a paid period, assigning a responsible person or notifying a team. For goods, it may mean authorising picking, preparing documents, transferring an order for shipment or informing the responsible employee.
The choice of action 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 amount, currency, customer, payment purpose and the link to the specific invoice. For some operations, manual confirmation remains appropriate even where the match is correct.
The source of payment confirmation is defined by the architecture of the particular solution. It cannot automatically be attributed to SEF or assumed to be the same for every company. Where verification should trigger picking or order transfer, the project on order-processing automation illustrates a connection with the operational workflow.
Exceptions, security and control
The main flow often looks straightforward, but the quality of a solution is determined by how it behaves in non-standard situations. Before launch, the company should document at least the following cases:
- Error or rejection. Who receives the task, where is the reason recorded and how does the operation return to the main flow?
- Correction. Which subsequent actions must be stopped, and who confirms the change?
- Partial or combined payment. May fulfilment continue, or must the decision go to accounting?
- Duplicate. How are repeated document creation and repeated service activation prevented?
- Incomplete data. Who completes the details and verifies the correction?
- System unavailability. Where is the operation retained, and when is intervention required?
- Manual change. Who is authorised to make it, and how is the action reflected in the log?
Every exception needs an owner, an acceptable response period and an unambiguous final state. “Exchange error” is not enough: the employee needs the order number, document type, reason for the stop and a safe action they can take.
A financial workflow concerns company details, amounts, documents and employee permissions. Access should be granted by role: a manager does not necessarily need authority for accounting corrections, and a technical specialist should not make a financial decision. Changing a critical rule or manually launching a risky operation may require additional confirmation.
The log should retain the data used, operation time, changes, reason for stopping and basis for continuation. If one system is unavailable, an operation must not disappear or be incorrectly considered complete. A retry, notification or transfer to the responsible employee is defined in advance.
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.
Stages of eFaktura integration implementation
Automatic invoicing is more reliable when introduced in stages. Trying to cover every sales type, document, branch and exception at once makes verification harder and obscures the causes of errors.
- Map the process. Record data sources, manual actions, systems, roles and decision points.
- Review connectivity. Confirm software versions, available interfaces, the SEF access procedure and infrastructure constraints.
- Agree the field table. Define mandatory values, formats, identifiers and owners of accounting rules.
- Describe exceptions. Set behaviour for duplicates, incomplete data, ambiguous payments and system unavailability.
- Pilot one flow. Select one understandable transaction type and reconcile the result with the current procedure.
- Acceptance. Check permissions, logs, retries, notifications and manual approval of risky actions.
- Expansion. Add new document types and subsequent processes only after the previous stage has been checked.
A project’s timeframe and cost cannot be stated accurately without assessing the systems, document volume and company rules. Even identical accounting applications may be configured differently, and the same invoice type may trigger different actions in two organisations.
What to prepare for an engineering assessment
Before discussing implementation, prepare a short description of the current process. State where the order is created, who confirms its composition and value, which accounting application is used, which electronic invoice types are involved and how employees currently learn that a document’s status has changed.
Describe payment separately: where confirmation comes from, whether partial or combined payments are possible, which data is used for matching and what action must follow. Anonymised field examples and a list of exceptions the team encounters in real work are useful additions.
For an operating environment in Serbia, it is also necessary to define the language of fields and notifications, transaction currency, composition of the customer directory and the person responsible for checking accounting rules. These parameters cannot be assumed in advance: the client records them with their accountant, after which the technical team evaluates the data route and control points.
Only then can the team determine whether controlled file exchange is sufficient, whether a direct connection is possible and which checks are needed before the next action starts. The outcome of the assessment should be a clear map of systems, fields, owners and exceptions—not a promise of universal compatibility.
