Why won’t the REK-O be built?

You tried to close a payroll run or file the REK-O to eDavki, and the app refused. Nothing was sent to eDavki. FURS requires several facts about the company, the employee and the payment subaccounts for the REK-O, and the app deliberately never guesses them, since a wrong value would mean a wrong tax filing. The message names which fact is missing and where to enter it.

What the screen says

Collective agreement code (S02)

The collective-agreement code (šifra kolektivne pogodbe) is recorded neither on the employee’s contract for this period nor for the company, so the REK-O could not be built and nothing was sent to eDavki. It cannot be inferred: 999 states that no collective agreement binds this employment, and a sector agreement with extended validity binds regardless of membership, and only the employer can state it. Record it on the employee’s contract, or for the whole company under Settings → Company, in the ZZZS and AJPES identifiers card, and file again.

Enter it under Company Settings, in the ZZZS & AJPES identifiers card, in the Collective agreement code field (its info icon names the REK-O field it fills, S02). If a different collective agreement binds one employee, enter the code on that employee’s employment contract instead, in the Collective agreement code (REK-O S02) field; it overrides the company code.

Payment date (F012)

The payment date (datum izplačila dohodka) is missing or is not a real calendar date, so the REK-O could not be built and nothing was sent to eDavki. That date sets the FURS deadline for paying the withheld tax and contributions, so it is never filled in for you, so enter the actual payout date on the payroll run and file again.

You enter this date on the payroll run itself, not in company settings: open the run, click File, and in the Payment date (datum izplačila) field enter the day the pay actually went out, not an arbitrary or default date.

Person responsible for REK filings (F008)

The person responsible for preparing the REK form (odgovorna oseba) is not recorded, so the REK-O could not be built and nothing was sent to eDavki. FURS requires fields 008 and 009. Record the name under Settings → Company, in the ZZZS and AJPES identifiers card, and file again.

Enter it in the same card, in the Person responsible for REK filings field (its info icon names it as REK-O field F008).

Responsible person’s contact (F009)

The responsible person’s contact details are not recorded, so the REK-O could not be built and nothing was sent to eDavki. FURS requires fields 008 and 009. Record them under Settings → Company, in the ZZZS and AJPES identifiers card, and file again.

Enter it in the same card, in the Responsible person’s contact field (its info icon names it as REK-O field F009): a phone number or email for the same person you recorded for F008.

Employee first and last name (A003a)

The employee’s name could not be split into a first and last name, so the REK-O could not be built and nothing was sent to eDavki. FURS requires both separately (fields A003 and A003a). Record the employee’s first and last name on their coworker record, and file again.

This happens when an employee’s name is recorded as a single string (for example just a surname, or the full name in one field). Fix it under Coworkers: open the employee and enter each part of the name in its own field, First name and Last name.

Company address

The company’s registered address (street, city, postal code) is incomplete, so the REK-O could not be built and nothing was sent to eDavki. eDavki checks the taxpayer header against the register. Complete the address under Settings → Company, and file again.

Check the Address field near the top of Company Settings. If it is filled in but doesn’t parse cleanly into a street, postal code and city, enter them separately in the ZZZS & AJPES identifiers card, in the Street and number, Post number and Post name fields.

Any other mandatory field

The REK-O could not be built: the mandatory field A006 could not be derived from this payroll run. Nothing was sent to eDavki. Contact support and quote the employee and the period.

FURS payment subaccounts

FURS requires its own payment subaccount for every contribution family the REK-O declares. The FURS payment subaccounts (REK-O) card in Company Settings normally fills these in for you, from the FURS register.

When one is missing outright:

No FURS payment subaccount (income-tax withholding) is recorded for this company, so the REK-O could not be built and nothing was sent to eDavki. FURS requires a payment subaccount for every contribution family the form declares, and it is never derived for you. Open Settings → Company, record it by hand in the FURS payment subaccounts card, and file again.

When one is recorded but isn’t a valid Slovenian payment account:

The FURS payment subaccount recorded for income-tax withholding is not a valid Slovenian payment account, so the REK-O could not be built and nothing was sent to eDavki. Open Settings → Company, correct it in the FURS payment subaccounts card, or clear the field to use the account from FURS’s own register, and file again.

In more detail, when the account number fails its checksum:

The payment subaccount entered for income-tax withholding is not a valid Slovenian payment account, the account number fails its checksum. Check it against your FURS records, or leave the field empty to use the account from FURS’s own register.

When the recorded subaccount is a valid IBAN but not the one FURS’s register lists for that contribution:

The payment subaccount entered for income-tax withholding is not the account FURS’s register lists for that contribution. It should be SI56 0110 0888 1000 030. Correct it, or leave the field empty to use the register value automatically.

If you try to fetch the subaccounts from eDavki automatically:

The FURS payment subaccounts cannot be fetched from eDavki automatically: that fetch logs in to eDavki as a person, and a person’s certificate may only be used by that person. Nothing was sent to eDavki. The REK-O uses the subaccounts from the FURS register; record any that differ by hand under Settings → Company.

This is not an error in your own data. The app does not fetch subaccounts from eDavki, because that would need a person’s certificate without that person present. Enter any subaccount that differs from the register in the FURS payment subaccounts (REK-O) card by hand.

The contribution bases contradict each other

The pension-basis amounts on this payroll run add up to more than the contribution base it declares, which FURS refuses outright. Nothing was sent to eDavki. This means the run’s own figures are inconsistent, not that anything is missing from it. Contact support and quote the employee and the period.

A related but separate message appears when an employment contract has no weekly working hours recorded:

The employment contract for this employee records no weekly working hours, so the monthly sklad ur, and with it the pension basis reported in M01, cannot be computed. Nothing was sent to eDavki. Open the contract, enter the contracted weekly hours, and file again.

You enter that under Payroll → Contracts: open the employee’s contract and fill in the Hours per week field.

Holiday allowance paid before the move to this program

This organization’s payroll moved to this system partway through 2026, and the holiday allowance already paid to Maja Novak before the cutover is not confirmed. The annual tax-free ceiling is shared across every holiday-allowance payment in the calendar year, and any income tax already withheld has to be credited against this one, so a payment made in the previous system still counts.

This appears when you draft a holiday-allowance (regres) run, before any REK-O exists. It concerns organizations that moved to this program mid-year: the employee stayed with the same employer all year and only the payroll software changed. A payment made in the old program is invisible here, so without this figure a second payment would be treated as entirely tax-free and the filing would be wrong.

There are two figures, and you record both under Payroll → YTD carry-in → Employee facts. In the Regres from THIS employer before cutover (gross, EUR) column, enter the gross amount of the whole payment. In the …income tax withheld on it (EUR) column, enter the income tax the previous provider withheld from it.

Enter the gross amount, not the tax-free part. If the payment went over the annual ceiling, the program works out the settlement from the gross amount and the tax withheld; it cannot do that from the tax-free part, because that figure stops at the ceiling. The two belong together — the program requires both or neither. If no holiday allowance was paid before the cutover, enter 0 in both: an explicit zero is a valid answer and the run then drafts.

Performance bonus and winter holiday allowance paid before the move

This organization’s payroll moved to this system partway through 2026, and the performance bonus and winter holiday allowance already paid to Maja Novak before the cutover are not confirmed. From 2026 the two share one annual tax-free ceiling and at most two performance-bonus payments a year, so payments made in the previous system still count.

This appears when you draft a winter-holiday-allowance (zimski regres) run. From 2026 the performance bonus and the winter holiday allowance are measured against one shared annual ceiling, so a performance bonus paid by the previous provider reduces the tax-free part of the winter allowance you can pay now.

Record these in the same place, in the Performance bonus + winter regres before cutover (gross, EUR), …of which in the tax base (EUR) and …income tax withheld on it (EUR) columns. All three belong together — the program requires all three or none, because the annual income-tax settlement credits the tax already withheld. If there was no such payment before the cutover, enter 0 in all three.

Why this happens

The REK-O is a tax filing that goes straight to FURS, so the app never guesses any of these facts or substitutes a reasonable-looking default: only the employer can state the collective-agreement code, the payment date and the responsible person, and a payment subaccount has to match FURS’s own register. If any of them is missing or invalid, the app refuses to build the form at all, rather than send FURS a filing with a made-up or invalid value. The contribution-base message (M01 through M10) is a different kind of problem: it isn’t a missing fact, it’s the run’s own figures contradicting each other, which needs support to review.

What to do

1. Find the field or card name the message names (for example S02, F008, F009, or “FURS payment subaccounts”).

6. Once the missing fact is entered, retry closing the run or filing the REK-O.
7. If the message names the contribution bases (M01 through M10), any other mandatory field without a named location, or a connection error with eDavki that persists after entering the subaccounts by hand, don’t try to fix it yourself: go straight to the last section below.

If you can’t fix this yourself

Company settings (ZZZS & AJPES identifiers, FURS payment subaccounts, address) can only actually be saved by a user with the Administrator or Računovodja (Accountant) role. If you don’t hold one of these roles, ask someone who does.

For a contribution-base mismatch (M01 through M10), for any other mandatory field the message doesn’t name a location for, and for a connection error with eDavki that persists even after entering the subaccounts by hand, contact support and quote the employee and the period the run covers.