Sidrena cijena: The XML/CSV Price List for Web Shops

Two requirements in the decision are easy to miss.

File names carry metadata. Point VI says file names include the type of sales outlet, its address, its outlet label, a "broj pohrane" (storage number) and a timestamp with the date and time of publication. As of 24 September 2026, nobody has officially defined "broj pohrane". We treat it as the outlet's internal number and keep it stable.

Machines must be able to fetch the file. Point VII obliges traders to allow software tools and automated programs to collect price data. Our reading: a file behind a login, a cookie wall or a bot challenge from your firewall does not meet that, even if a person can open it in a browser.

A build that holds up

Here is the setup we would put on a Next.js shop or any other custom stack. The same pattern works for a PHP or Python backend.

• Anchor price per item (anchor price decision, point II): a price_anchor column plus a price_anchor_date column, filled once and never overwritten.
• XML or CSV, machine-readable (price list decision, point II): generated from the database, UTF-8, header row, one row per SKU.
• Products refreshed daily by 8:00 (point II): a scheduled job around 6:00 with an alert if it fails, so there is time to rerun it.
• Services refreshed on price change (point II): the same job, triggered when a service price is saved.
• Metadata in the file name (point VI): for example webshop_<address>_<outlet>_<storage>_<YYYY-MM-DDTHHmm>.csv.
• 30-day availability (point II): every file written once to object storage and never overwritten, an index page that lists them, deletion only after 30 days.
• Open to automated tools (point VII, our reading): a public URL, excluded from bot challenges and login, and not blocked in robots.txt.

A CSV header and one product row could look like this (semicolon-delimited, since product names often contain commas):

naziv;sifra;marka;jedinica_mjere;cijena_za_jedinicu;mpc;posebni_oblik_prodaje;sidrena_cijena;barkod;dostupnost

Maslinovo ulje 0,5 l;OL-050;Uljara X;l;25,80;12,90;;12,50;3850000000000;dostupno

The field names are our own example, not an official format, and the barcode is a placeholder EAN.

Where the anchor price comes from

This is the hardest part in practice. If your shop kept a price history table, the anchor is one query. If it did not, the usual sources are, in order of reliability:

1. a database backup from 10 September
2. order lines from that day, for products that sold
3. an export to price comparison sites or a marketplace feed from that date

The anchor price decision itself says the anchor excludes special forms of sale. So if a product was discounted on 10 September, the anchor is its regular price. For products introduced after that date, the Ministry's clarification, as reported by N1, says the anchor is the first price they were sold at, with the date clearly shown. That is why the anchor needs its own date column: one shop can hold SKUs anchored on 2 May 2025, on 10 September 2026 and on a later launch date.

Store the source of each anchor price next to the value as well. If an inspector asks, "taken from the 10 September backup" is a better answer than a number with no history.

For products with configurable prices, the Ministry's clarification says the anchor price is shown for the individual elements the final price is calculated from, not for each customer's quote.

One source of truth

The anchor price also has to appear next to the current price on the product page and in online advertising. If the page reads one field and the file generator reads another, they will drift apart. Both should read the same price_anchor and price_anchor_date columns, and both should be read-only in the admin panel.

Questions shop owners are asking

"I have 500+ products. How do I put this list together?" You don't build it by hand. It is generated from the same database the shop already uses, so 500 products take the same effort as 50.

"My products have no barcode. Can the field be empty?" The decision lists the barcode without the "where applicable" qualifier it gives the unit fields, and it does not say what to do when there is none. We leave the field empty rather than invent a number, and we recommend asking the Ministry in writing.

"My site shows no prices. Do I still publish a list?" The Ministry says the duty covers informational websites too. HOK's guidance says you still publish the file.

What we would check before 1 October

• The file opens at a public URL without cookies or a login, and a curl request gets a 200 response, not a challenge page.
• The CSV or XML parses cleanly: the right encoding, the delimiter used consistently, no line breaks inside fields.
• Every active SKU has an anchor price, an anchor date and a record of where the price came from.
• The scheduled job writes a new file with a new timestamp and leaves yesterday's file untouched.
• Someone gets notified if the 8:00 file did not appear.

None of this is a redesign. It is two table columns, a scheduled job and a storage bucket. Most of the risk sits in the data (the anchor prices) and in the details (the URL being reachable), not in the code.

If your shop runs on a custom stack and you are not sure it will pass this list, we build and maintain and can tell you where yours stands. Send us your shop's URL through the contact form.

This post explains the technical side of the rules as published in NN 101/2026 and the Ministry of Economy clarification of 22 September 2026. It is not legal advice. For edge cases, ask the Ministry or your accountant in writing.