Serbian regulation, down to the form number
This page exists so that you can check us. Each obligation states what the law requires, what NG One does about it, which channel it travels and by when — named the way the statute names it, because that is how an accountant checks. What the law leaves with you — the certificate, the account with the service, the authorised person's signature — is written here too, because no ERP makes a company compliant by itself.
- SEF e-invoices and VAT records
- e-Delivery notes and CRF
- ePorezi without an API
- Payroll, PPP-PD, CROSO
- Fiscalisation LPFR/VPFR
- e-Archiving and signatures
How to read this page
Compliance is not a list of ticks. It is the question of whether a system can show why something was calculated the way it was — and whether it can still show that for a document three years old.
In 2026 the Serbian state merged invoicing, VAT records, delivery notes and the invoice registry into a single ecosystem around SEF. The natural response is to merge all of it inside the system too, into one module that “does SEF”. NG One deliberately declines that. The flows are connected in the domain — invoice, record, delivery note and registry share one graph of business objects, so the link between them is a business fact rather than a copied field. Towards the services, however, each has its own adapter, its own lifecycle, its own synchronisation status and its own watermark. When SEF changes its rules in April, one adapter changes and the e-delivery note and CRF keep working. Connected in the domain, separated in integration — a structural advantage without a dangerous coupling.
The second decision separates the file from the channel, and it shows on every item on this page. Records in the EEO and EPP structure, POPDV, PP PDV, PPP-PD, the tax balance, the APR statement and the UBL 2.1 invoice are documents NG One produces from the same lines that produced the postings — one record, not a derived spreadsheet filled in against a deadline. The channel is a separate job: SEF, SEO, CRF and fiscalisation expose real APIs, so exchange there is automatic, with statuses and retries; ePorezi has no public API, so that flow is semi-automatic — preparing, validating and signing are ours, the act of filing stays on the portal with the authorised person. The separation works in your favour too: the file is correct even when you file it through the channel you already use.
The third decision is the only one that cannot be repaired later: effective-dated statutory parameters. In Serbia, rates, tax-free amounts, thresholds and mappings change mid-year — sometimes with retroactive effect. A system that holds a parameter as a single value in settings has only the present: correct a March document in December and the calculation follows December's rules, the result is wrong, and nobody notices until an inspection. In NG One every statutory parameter is a record with a validity period, and each posting carries the version of the rule that produced it. So a correction to a past-period document follows the rules that applied then, and the answer to “why is this exactly this much” is read from the record instead of reconstructed from memory. A decision like that is made before the first posting or never: systems that grew over years lack it in their core precisely because it cannot be added without reposting history.
Finally: no ERP makes a company compliant by itself. An authorised person files the return, the company holds the certificate, and responsibility for accuracy remains with the taxpayer. What a system can do is make the obligation visible before the deadline, prepare the file correctly, and support every claim with data traceable to the source document. Everything beyond that is marketing.
Obligations NG One covers
Six groups organised by who asks what of you and by when. Each item states what NG One does about it — named the way the statute names it.
Electronic exchange with the state
In 2026 the state merged invoicing, VAT records, delivery notes and the invoice registry into a single ecosystem around SEF. NG One connects those flows in the domain, while keeping a separate adapter with its own lifecycle for each service.
SEF e-Invoices — outbound and inbound
Public-sector and VAT-registered entities issue and receive invoices exclusively through the SEF system, and an inbound invoice must be accepted or rejected within 15 days. NG One produces the UBL 2.1 document from the sales flow, sends it and tracks status (sent, accepted, rejected, cancelled), handles cancellations and advances, and pulls inbound invoices in, linking each to its purchase order and goods receipt with a proposed match.
The document is UBL 2.1 in the Serbian CIUS profile, with cancellations and advance invoices. An inbound invoice is never re-keyed: a human confirms the proposed match to the purchase order and goods receipt, so the 15-day deadline is carried as a task with an owner rather than a calendar reminder.
SEF VAT records — EEO and EPP
The electronic VAT calculation record (EEO) is filed within 10 days of the tax period closing, while the individual input-tax record (EPP) is due by the 12th of the following month, with its own rules on the state of data as at the 10th. NG One derives both records from the same lines that produce the postings, and reads the deadlines from the compliance rule pack, with the rule version and legal source kept in the audit trail.
EEO and EPP have different deadlines and different rules — neither is hard-coded; both come from the versioned rule pack and shift for non-working days.
e-Delivery note (SEO)
The electronic delivery note is created before goods move and follows them through to receipt confirmation, carrying carrier and vehicle details and its link to the e-invoice. NG One derives it from the delivery note that already exists in the inventory and logistics flow, tracks status and the e-receipt, and runs a distinct flow for excise goods.
CRF — Central Invoice Registry
Receivables from the public sector are registered in the Central Invoice Registry, and since 1 July 2026 the CRF ID is derived from SEF. NG One stores the CRF ID on the invoice, tracks settlement per JBKJS, and reconciles open items without anyone re-keying from the portal.
eGovernment — eMailbox and eID
Acts issued by state bodies are delivered to a legal entity electronically, into the eMailbox, and are deemed served once the deadline lapses whether or not anyone opened them. NG One routes an incoming act into the registry book and DMS, so the document gets a number, a deadline and an owner the moment it arrives, with eID (ConsentID) available as a sign-in option for signatories.
The clock starts on delivery into the eMailbox, not on opening — an act nobody read is still an act duly served. That is why receipt enters the registry book automatically, rather than when someone finds time to check the inbox.
VAT and taxes
A tax obligation does not arise at period end from summary figures; it arises on each document line, under the rules that applied on that document's date. That distinction decides whether the past can be shown accurately at all.
VAT engine (internal)
A registered entity maintains records in the EEO and EPP structure and answers for the accuracy of the tax treatment of every line, not just the total. The NG One VAT engine determines the treatment on the document line as it is created, under the mapping in force for that tax period, so the record and the posting cannot drift apart — they come from the same entry.
POPDV and PP PDV
The PP PDV tax return is filed together with the POPDV calculation overview, and the figures in the return must agree with the records filed through SEF. NG One produces both as filing-ready XML from the same lines, with a control report reconciling them against the EEO and EPP records.
The control report runs before filing, not after an inspection: it shows every line on which PP PDV and the SEF records disagree, with a link through to the source document.
Corporate income tax — PB-1, PDP, PDPO, PPI-1
The tax balance (PB-1) and the corporate income tax return (PDP) are filed for the tax year, alongside PDPO for withholding tax and PPI-1 for tax depreciation. NG One derives them from the general ledger and the fixed-asset register rather than from a separate spreadsheet rebuilt every year.
ePorezi — filing signed XML
Returns are filed through the ePorezi portal, signed with the qualified certificate of an authorised person. NG One prepares, validates and signs the XML filings (PP PDV, PPP-PD, PDP and others), keeps a register of filings and their status, and issues deadline reminders — the act of filing itself stays on the portal.
ePorezi has no public API. The flow is deliberately semi-automatic: we automate preparing, validating and signing the file — we do not sign in to the portal on your behalf. Anyone claiming full ePorezi automation is describing something the service does not offer.
Effective-dated statutory parameters
Rates, thresholds, tax-free amounts, coefficients and mappings change mid-year in Serbia, and a correction to a document from a past period must follow the rules that applied then. In NG One every statutory parameter is a record with a validity period: a document dated in March is calculated under March's rules even when it is corrected in December.
A foundational decision, made before the first posting. A system that holds a parameter as a single value cannot acquire this later — it can only overwrite history.
Payroll and people
Serbian payroll is the widest gap in every foreign system: the calculation, PPP-PD, CROSO and eBolovanje are local statute that a global product covers through a localisation — and localisations lag the law. In NG One they are part of the core.
Payroll calculation
Pay is calculated from the contract, working time, length of service, deductions and reliefs, with employee and employer contributions and a tax-free amount that changes by statute. NG One runs the calculation over the same master data as the rest of the system and posts it straight into the dimensional general ledger — labour cost lands on the cost centre and the project at once.
The tax-free amount, contribution rates and the minimum and maximum bases change by statute mid-year — all are effective-dated parameters, so a re-run for a past month follows that month's rules, not today's.
PPP-PD return
The individual tax return PPP-PD is filed before every payment of income and must agree with the payment to the dinar. NG One produces it as XML out of the payroll run rather than from a spreadsheet filled in afterwards, so the return and the payment order come from the same record.
The order is statutory, not habit: the bank executes the payment only against the BOP returned by an accepted return. NG One therefore keeps the payment order tied to the return that produced it — return, BOP and order are one chain, not three files.
CROSO — registrations and deregistrations
Registration for mandatory social insurance is filed before work begins, with deregistrations and changes within prescribed deadlines — a lapse is an offence before any damage occurs. NG One maintains the register and prepares registrations, deregistrations and changes from the employment contract already in the system, automating as far as the portal permits.
eBolovanje (RFZO sick leave)
Sick-leave certificates are issued electronically, and the employer calculates the benefit from them and files for reimbursement. NG One retrieves the e-certificates, links them to the payroll run and manages electronic reimbursement claims with their status, so the absence, the calculation and the RFZO receivable are not tracked in three places.
The employer bears the first 30 days of the benefit and the RFZO the days from the 31st — the boundary runs per continuous incapacity, not per calendar month. NG One derives it from the certificate and the absence record, so the RFZO receivable comes out of the payroll run rather than a later recount of days.
Permanent retention of payroll records
Payroll calculation records are retained permanently — an employee's pension entitlement is established from them decades later. NG One keeps them as documents in the electronic archive, with an access trail and without depending on the payroll module still existing in the same form.
The obligation most often lost during an ERP change itself: the old system is switched off and the payslips stay inside it. That is why here they are not a report out of payroll but a document in the archive, with a retention period of its own.
Fiscalisation and retail
Retail turnover is fiscalised at the moment of sale through an electronic fiscal device, and from April 2026 the fiscal receipt and the e-invoice meet. That junction is where retail and VAT records have to agree.
e-Fiscalisation — LPFR/VPFR and ESIR
Every retail receipt passes through a fiscal receipt processor — local (LPFR, on a security element) or virtual (VPFR) — and the software assembling the receipt must be certified as an ESIR with the Tax Administration. NG One carries both adapters, all receipt types, QR verification, up to five days of offline operation and the journal.
ESIR certification is a Tax Administration procedure — the software is submitted, tested and issued a numbered decision; it is a matter of lead time, not code. The NG One fiscal layer stands on the same experience that produced NG eFiscal, a certified software ESIR from the Konis family.
POS, retail and the KEP book
A retail outlet maintains the turnover record book (KEP) and retail costings, and every price change requires a revaluation document. NG One keeps the KEP, retail and wholesale costings and revaluations over the same stock the wholesale business runs on — with no separate retail database reconciled overnight.
The KEP book is kept per outlet and updated no later than the day after the turnover it records. NG One fills it from the same documents that already post the stock movement, per outlet — the book is not a second entry of the same turnover.
Fiscal receipt ↔ SEF link (4/2026)
The April 2026 changes require retail sales to the public sector and corporate-card turnover to link the fiscal receipt and the e-invoice rather than record both. NG One keeps that link on the document, so the VAT record agrees with fiscalised turnover without anyone manually excluding double amounts.
Financial reporting
The annual report is not assembled in March — it is a consequence of how twelve months were posted. The chart of accounts and the fixed-asset register decide how hard that March is.
APR — financial statements
The regular annual financial statement is filed with the Business Registers Agency through its own information system, in a prescribed format and subject to prescribed checks. NG One produces the statement from the general ledger under the official chart of accounts, as a filing-ready file — with no balances re-keyed into someone else's form.
The regular annual statement is due by 31 March of the following year, signed with the legal representative's qualified certificate. APR prescribes the format and the checks — a statement that fails their validation is not filed at all, so we run the same checks before it goes.
Serbian chart of accounts
Companies post under the prescribed chart of accounts, and statements, the tax balance and statistics derive from it. In NG One the official chart is part of the foundation, and posting is configured through posting groups — a rule is effective-dated configuration, not a code change.
The architecture allows for multiple charts of accounts, but the official Serbian chart is the only one shipped.
Fixed assets — dual depreciation and PPI-1
Accounting and tax depreciation differ in Serbia and are maintained in parallel, with tax depreciation reported through PPI-1 alongside the tax balance. NG One keeps both books over the same asset, with stocktaking and value changes, so the difference between them is a standing state rather than an annual manual exercise.
Tax depreciation follows statutory groups rather than an estimated useful life, so the two books diverge from the first run. The difference therefore enters the tax balance as a state the system holds, not as a correction reconstructed backwards every March.
Archiving and signatures
An electronic document without an ordered archive and without a signature that survives a dispute is a file, not evidence. This is also where the most important caveat on this site sits — what is, and what is not, a qualified signature.
e-Archive book and the 30 April filing
A creator of documentary material maintains the archive book and submits a transcript for the previous year to the competent archive by 30 April. NG One maintains the archive book over documents already in the DMS and registry book, with categories and retention periods, and produces the transcript as a filing-ready document.
The list of categories and retention periods is adopted with the competent archive's consent, and it is the list against which destruction is later judged. In NG One it is effective-dated configuration: a new consent does not touch documents already archived under the old list.
Internal approval and signing
A decision inside the company — approving a purchase order, confirming a payroll run, adopting a document — must leave a verifiable trace of who decided and when. NG One runs signing flows on the workflow kernel, with an audited decision signature, approval limits and maker-checker control.
A line we do not paper over: this is a technological PAdES rendering and is NOT a qualified electronic signature. Inside the company it is enough — you know who approved what, and the document cannot be altered unnoticed after approval. A document that must survive a dispute with a third party or be filed with a state body needs a qualified signature or seal, with an issuer's certificate and a timestamp — the item below.
Qualified seal and timestamp
A legally valid electronic document carries a qualified signature or a legal entity's seal and a qualified timestamp, issued by a registered trust service provider. NG One connects to the issuer's certificate (Pošta, PKS, Halcom and others) and to a timestamping account, for the e-archive, e-signing and filings.
A registered trust service provider issues the qualified certificate to you, not to us — NG One binds to your certificate and your timestamping account. No system, ours or anyone else's, can mint a qualified signature in a trust provider's place; whoever offers that is offering something else under the name.
Advanced e-signing and flows
A contract, an addendum or minutes require multiple signatories, a signing order and proof of document integrity after signing. NG One extends the internal flows with advanced signing over the DMS and registry book, with versioning and a trace of every change.
An advanced signature binds the signatory to the document and proves it was not altered afterwards. The legal presumption of validity before a state body comes only with a qualified certificate and a timestamp — the difference is legal rather than technical, and it is chosen per document.
Does NG One make us compliant with Serbian regulation?
A company is compliant, not a piece of software — an authorised person files the return, the company holds the certificate, and responsibility for accuracy stays with the taxpayer. What NG One does is make the obligation visible before the deadline and produce the file correctly, out of the same lines that produced the postings: the Serbian chart of accounts in the foundation, the VAT engine with EEO and EPP records, POPDV and PP PDV as filing-ready XML, UBL 2.1 invoices through SEF in both directions, e-delivery notes and CRF, payroll with PPP-PD, CROSO and sick leave, the tax balance and the corporate income tax return, the APR statement, fiscal receipts through LPFR or VPFR, the KEP book and the archive book with its 30 April transcript. Each item on this page states what the law requires, what we do about it, and what the law leaves with you. Take the list and check us against it — that is what it is for.
What is harder — the link to a state service, or correct data?
The connection is not the hard part. The hard part is producing correct data: an invoice whose VAT treatment agrees with the record, a delivery note that matches the actual movement of goods, a payroll run that survives an audit. That is why in NG One the document and the file come out of the same lines that produce the postings, so the SEF adapter sends something that is already correct rather than something re-keyed into another format on the way out. The reverse order pays off for nobody: a system with the connection but not the model sends the state exactly as many errors as its model contains — only faster, and with a delivery receipt.
What exactly does it mean that ePorezi “has no API”?
It means the ePorezi portal offers no public programmatic access for filing returns. Filing happens through the portal, signed with the qualified certificate of an authorised person. Our flow is therefore deliberately semi-automatic: NG One prepares and validates the XML (PP PDV, PPP-PD, PDP and others), signs it with a qualified certificate, keeps a register of filings and their status, and issues deadline reminders — while the act of filing stays on the portal with the authorised person. That is the service's limitation, not ours, and any vendor promising fully automatic ePorezi filing is describing something the service does not permit. SEF, SEO, CRF and fiscalisation, by contrast, have real APIs, and there the automation is complete.
Does NG One sign documents with a qualified electronic signature?
With your certificate, yes. A qualified signature, a legal entity's seal and a timestamp are issued to the legal entity by a registered trust service provider, and NG One binds to that certificate and to a timestamping account, for the e-archive, for signing and for filings. No system can mint a qualified signature in a trust provider's place, so anyone claiming otherwise is offering something else under the name. Separate from that sits internal approval on the workflow kernel: an audited decision signature, approval limits, maker-checker and a technological PAdES rendering. Inside the company that is enough — you know who approved what and when, and the document cannot be altered unnoticed after approval — but it is NOT a qualified electronic signature and must not be presented as one. We write the distinction wherever the claim appears, because it is the difference between evidence and a file.
What do “effective-dated statutory parameters” mean in practice?
Take a March document corrected in December, after a rate or a tax-free amount changed. In a system that holds the parameter as a single value, the correction follows December's rules — the result is wrong, and the difference surfaces only at an inspection or the annual reconciliation, when nobody can trace where it came from. In NG One the parameter is a record with a validity period, so a March document is calculated under March's rules even in December, and the posting carries the version of the rule behind it. In practice: backdated corrections are accurate, “explain this posting” works for last year too, and a change in the law does not corrupt history. It is one of five decisions that cannot be added afterwards — they were made before the first posting, because after it they can only be simulated by rewriting history.
The state merged SEF, VAT records, e-delivery notes and CRF — why do you separate them?
We separate them only where separation protects, and join them where joining helps. In the domain they are connected: invoice, record, delivery note and registry share one graph of business objects, so the link between them is a business fact rather than an operator's task. Towards the services, each has its own adapter with its own lifecycle, statuses and watermark. The reason is simple: these are different systems, with different deadlines, different rules and different days on which they fail. An integration layer that assumes shared state across distinct external systems will one day halt three flows because one service broke. With us, SEF can change its rules in April without a single change to the e-delivery note.
Who configures the links to state services — do we need a developer?
No. Every link is configured through the console, per tenant and per legal entity within a tenant: environment (demo or production), credentials in the secrets vault, which services are enabled, synchronisation schedules. Each link has a test-connection button and a health status on the compliance dashboard. Credentials never go into code or git, and every service has a sandbox profile, so production is switched on per client when that client is ready. This is a requirement, not a by-product: a consultant must be able to set up a new client without a developer, otherwise every new client becomes a project.
What do we need to provide for the links to work?
What the state issues to you rather than to us: an account and an API key per legal entity for SEF and SEF VAT records, an SEO account, access to a CRF environment, registration with the NBS web service for exchange rates, sample real statement files for your banks, a qualified certificate for signing ePorezi filings, a legal entity eID account with authorisations for eGovernment, sick leave and CROSO, access to the TAP portal and a security element for fiscalisation, and an issuer's certificate for the seal and timestamp. We ask for the list at the start of an implementation rather than shortly before go-live — the most common cause of integration delay is not code but waiting on an account a third party issues.
Does this work for an accounting firm with many clients?
Yes, and for compliance what matters is exactly where the boundary sits: links are configured per legal entity within a tenant, so each client has its own SEF key, its own certificate and its own profile, in the same installation, with data isolation enforced at the database level. A consultant works across the client portfolio, with bulk actions and a comparison of obligation status per client, and the compliance dashboard holds deadlines and link health for every client in one place. The distinction matters: a mode not anticipated at the start is later solved with a separate database per client, and from then on the firm pays for every upgrade as many times as it has clients.
What happens when the law changes after we go live?
In NG One the law changes as configuration, not as a version of the code. Deadlines, rates, thresholds and mappings live in the compliance rule pack, with a validity period, a rule version and the legal source; a new rule enters as a new record effective from its date, and the old one stays because a correction to a document from that period is still calculated under it. When a channel changes — SEF's schema, say — one adapter changes and the e-delivery note, CRF and fiscalisation keep working. And that is why a regulatory update does not require a project on your side: a clean core means your configuration is not a modification of the core, so an upgrade does not trample your mappings and your cases.
Test us against your own obligations
Book a working compliance review. We go through your tax cases, how you work with SEF and the deadlines that bind you — and show exactly what NG One does about each of them, traceable to the source document, and what the law leaves with you and your authorised person.