Most organisations in Serbia have solved e-invoicing in the narrow sense. Invoices go out through SEF, invoices come in through SEF, deadlines are mostly met. What has not been solved is that the portal and the accounting system are two different places, and every invoice now exists in both. That duplication is quiet, it is permanent, and it is where most of the remaining cost sits.
This post is about what actually changes when the exchange happens inside Business Central instead of in a browser tab next to it — and why the bigger win is not SEF at all, but what happens when SEF invoices and e-mailed PDFs end up in the same queue.
The outgoing flow, and why it is the easy half
Outgoing is the half that most people get comfortable with first. Inside the system, the flow is short: the invoice is created and posted in Business Central, it is sent to SEF in the prescribed UBL format either with one click or automatically as part of posting, and the SEF status comes back onto the invoice record.
That last part is the one that matters operationally. Sent, delivered, accepted, rejected, cancelled — those are states of a commercial relationship, not just of a file transfer. When they live on the invoice, a collections conversation starts from fact rather than from memory. When they live on a portal, someone has to go and look, and “the customer says they never got it” becomes an afternoon.
There is a second, less obvious effect. If sending is part of posting, the invoice cannot be sent in a form that differs from the one in the ledger. Re-keying an invoice into a portal quietly allows a different amount, a different VAT rate or a different due date to reach the customer than the one that is booked. Removing the second keystroke removes that whole class of discrepancy.
The incoming flow, where the work actually is
Incoming invoices are the expensive direction, because each one needs a decision from a human being and that decision has a deadline attached. Handled inside the system, the flow looks like this:
- The system periodically pulls new incoming invoices from SEF, so nobody has to remember to check.
- Vendor, amounts, VAT and due date are recognised automatically and a draft purchase invoice is created in Business Central.
- The responsible person reviews it in the system, against the purchase order if there is one, and approves or refuses it.
- Accepting or rejecting on SEF is done from Business Central, without logging into the portal.
- Once approved, the invoice is posted and enters the payment plan.
Compare that with the portal version of the same five steps: someone opens the portal, reads the invoice, decides whether it is legitimate — often by asking a colleague over chat — accepts it on the portal, then types it into the ERP so that it can be paid and booked. The invoice is read twice, entered once, and the reasoning behind the acceptance is recorded nowhere.
Acceptance deadlines are an operational problem, not a legal one
Everyone knows incoming e-invoices have to be accepted or rejected within a defined period. The reason deadlines get missed is almost never ignorance of the rule. It is that the queue is invisible to everyone except the one or two people with portal credentials, and those people also have month-end to close.
Moving the queue into the ERP changes the shape of that risk. The pending invoices are a list in the system that the finance lead can see, sort and assign. Approval can be routed by amount or by cost type, so a small carrier invoice does not wait for the same signature as a large capital purchase. Approvals can be given from Teams, which means the person who has to approve does not need to be at a desk with a portal login. And because the invoice is in the system from the moment it arrives, an unapproved invoice is visible as an obligation rather than as an absence.
The audit trail you get for free
When acceptance happens on a portal and booking happens in an ERP, the connection between the two is a person's recollection. When both happen in one system, you get an ordinary, boring, complete record: which invoice arrived when, which draft it created, who reviewed it, against which order and which budget dimension, who approved it, when it was accepted on SEF, when it was posted and when it was paid.
That record is worth more than compliance comfort. It is what makes it possible to answer questions that are otherwise unanswerable: how long approvals actually take, which cost centres approve slowly, whether duplicate invoices are being caught, how much of a programme's budget is committed but not yet posted. None of these require a reporting project. They fall out of having the events in one place.
The invoices SEF never touches
Here is the part that gets left out of most e-invoicing discussions. A large share of incoming invoices does not arrive through SEF at all. Foreign suppliers, hotels, carriers, event organisers, cloud services and international federations send a PDF by e-mail. Those invoices carry real cost, real VAT treatment and real deadlines, and they are the ones most reliably retyped by hand.
So an organisation that has automated SEF perfectly can still be running two incoming processes: an automated one for domestic e-invoices and a manual one for everything else. The second process is where duplicates, late settlements and unrecorded commitments accumulate — precisely because it has no queue and no status.
The fix is symmetrical with SEF. The organisation defines one or more inbound addresses. The system takes the attachment, recognises vendor, invoice number, date, amounts, currency and line items, and creates a draft purchase invoice with the original PDF attached to it. The recognised data is matched against existing vendors and, where one exists, against a purchase order. Then the invoice enters exactly the same approval flow as an invoice from SEF.
Why merging the two queues is the real win
Once both channels produce the same kind of draft in the same list, the question “where did this invoice come from?” stops being interesting. There is one inbox of incoming invoices, one approval flow, one place to look for what is outstanding, and one audit trail regardless of channel.
That has three consequences worth naming. Control becomes complete rather than partial: nobody can commit the organisation to a cost through a channel that has no queue. Reporting becomes honest: the payables position includes the PDF from the hotel, not only the domestic e-invoices. And the finance team's process becomes teachable, because there is one process to teach instead of two with informal exceptions.
What this does not do
It is worth being plain about the limits. Automatic recognition of a PDF is very good, not infallible; a badly scanned invoice still needs a human to correct a field, which is why the draft is a draft and not a posting. Merging channels does not decide whether a cost is justified — approval flows route that decision, they do not make it. And none of this removes the need for someone in finance to understand VAT treatment; it removes the need for them to spend the period typing.
What it does remove is retyping, invisible queues, missed acceptance deadlines and the uncertainty about who approved what and when. For most organisations that is the difference between e-invoicing as an obligation and e-invoicing as an improvement.
A live demo runs on a real invoice from SEF and a real PDF from e-mail, in one approval queue.