Every few months we meet a finance team that has done everything right and is still unhappy. They chose Microsoft Dynamics 365 Business Central because it is a serious system, because the group already runs Microsoft 365, because it is in the cloud and because nobody wanted to buy another server. The implementation went fine. And then, in the first VAT period, someone opened Excel — and never closed it again.
This is not a failure of the product. It is a misunderstanding about what a global ERP is for. Understanding that boundary properly is the difference between an ERP that carries the whole finance function and an ERP that becomes an expensive place to store journal entries while the real work happens elsewhere.
What a global ERP actually contains
Business Central ships worldwide. What Microsoft builds and maintains is the part that is genuinely the same everywhere: double-entry bookkeeping, a customer and vendor ledger, bank reconciliation, purchase orders and approval workflows, inventory, projects with budget and actual cost, fixed assets, a dimension model that lets any posted amount carry a programme, project, funding source or cost centre, and a reporting engine that talks natively to Excel and Power BI.
That is a lot, and it is genuinely good. The dimension model in particular is the feature most organisations underestimate: it is the reason a federation can report cost per programme, per discipline and per funding source from the same posted transactions instead of maintaining three parallel spreadsheets. None of that needs localising, because a cost centre means the same thing in Basel as it does in Belgrade.
What it deliberately does not contain
Statutory content is national, and it changes on a national schedule. Microsoft maintains localisations for a set of markets directly, and leaves the rest to partners in those markets. Serbia is one of the markets where the statutory layer is a partner responsibility. In practice that means a standard Business Central environment, out of the box, has none of the following:
- No exchange with SEF, the national e-invoicing system — no sending in the prescribed UBL format, no pulling of incoming invoices, no acceptance or rejection.
- No POPDV. The VAT records that the Tax Administration expects simply do not exist as a report.
- No Serbian statutory chart of accounts, so the account structure is either invented locally or copied from the group and then reconciled by hand.
- No automatic download of the National Bank of Serbia exchange rate list, and therefore no correct calculation of exchange differences on the official rate.
- No statutory financial statement forms — the balance sheet and income statement in the shape the authorities require.
- No Serbian-language document layouts with the mandatory elements: prepayment invoices, credit notes, statements of account, delivery notes.
- No cash desk or travel order handling of the kind local practice and local audit expect.
- No connection to fiscal devices for retail.
Read that list again as a finance manager rather than as an IT buyer. Every line is something that has to happen anyway, on a deadline, with a penalty attached. If the system does not do it, a person does it.
The two ways organisations bridge the gap
The first way is to keep a local bookkeeping program alongside the ERP. The ERP runs the business — purchasing, projects, invoicing — and at the end of each period the numbers are transferred into the local program so that VAT and the statutory statements can be produced from a system the accountant trusts. This works, in the sense that filings get made. It also means two systems of record, a monthly reconciliation that nobody enjoys, and a permanent argument about which set of numbers is the real one.
The second way is Excel. The VAT records are rebuilt by hand from exports. SEF is handled on the portal: outgoing invoices are keyed in a second time, incoming invoices are read on the portal and then keyed into the ERP. Exchange rates are looked up and typed in. Institution and donor reports are assembled from exports before every deadline. This also works, right up until the person who knows how the workbook fits together is on holiday.
What the bridge actually costs
The cost is rarely on anyone's budget line, because it is paid in hours and in risk rather than in invoices. It shows up in four places.
- Duplicate data entry. Every invoice that exists both on SEF and in the ERP is typed twice, and every double entry is a chance for the amount, the VAT rate or the vendor to differ between the two records.
- Deadline risk. Incoming e-invoices have acceptance deadlines. When acceptance lives on a portal that only one or two people open, a missed deadline is not a possibility but a matter of time.
- Reconciliation work. Two systems of record need periodic agreement, and the work of agreeing them scales with transaction volume rather than with the size of the finance team.
- Audit exposure. When compliance output is produced in a spreadsheet, the audit trail is the spreadsheet's version history. There is no record of who approved a cost, when, and against which budget.
There is a fifth cost that is harder to name: the finance function stops being able to answer questions quickly. If the real position lives across an ERP, a bookkeeping program and four workbooks, then “how much of the programme budget is left?” becomes a small project instead of a query.
What a statutory layer changes
A localisation is not a set of report templates. Done properly it is an application installed into the Business Central environment that adds the national content to the standard product and is maintained against regulatory change. The practical test of one is simple: after it is installed, can the organisation meet every statutory obligation without leaving the system?
For Serbia that means SEF exchange in both directions with the status of each invoice visible on the invoice record; VAT records with POPDV and the VAT return prepared from posted data, including prepayment treatment; a Serbian statutory chart of accounts that can still be adapted to the organisation; automatic NBS rate download with exchange difference calculation; statutory financial statements generated from the system; Serbian-language documents with every mandatory element; cash desk and travel orders with advances and settlement; and fiscal device connection where retail applies.
A note for groups with a Serbian entity
If Business Central is already the group standard, none of this requires reopening that decision. The group keeps its processes, its chart of accounts logic, its reporting and its licence agreement. What the Serbian entity needs is the statutory layer added to its own environment, plus SEF exchange and local document layouts. Reporting then runs twice from the same posted data: in local currency and local form for the authorities, and in the parent's currency and group format for consolidation.
That is usually a much smaller project than the group expects — measured in weeks, not quarters — because the hard part, agreeing how the business is modelled, has already been done at group level.
The short version
Standard Business Central is a strong ERP that does not know Serbian law, and was never intended to. The gap is real, specific and enumerable — SEF, POPDV, the chart of accounts, NBS rates, statutory forms, local documents, cash and travel, fiscalisation. It gets closed either by people, every month, forever, or by a maintained statutory layer that updates when the rules do. The first option is not cheaper. It is just harder to see on a budget.
See the Serbian layer running on a real invoice, a real VAT period and your own chart of accounts.