Import při změně hlavičky kontroluje i uložené položky, které požadavek neobsahuje. Změna typu faktury, typu skladového pohybu, data zařazení majetku nebo zákazu účetních odpisů, po které by položky dokladu nebo daňové odpisy byly neplatné, se odmítne chybou 400. Odmítne se například změna faktury na dobropis s kladným množstvím na položce. Chyba označuje i uloženou položku, například polozkyFaktury[id=123].mnozMj.

Odpověď API na zápis (PUT/POST) jde zmenšit novým parametrem ?only-issues=true. V results pak zůstanou jen záznamy s chybou, varováním nebo nezodpovězeným dotazem, úspěšně uložené záznamy se nevypisují. Hodí se u velkých importů. Bez parametru se odpověď nemění.

Správce se serverovými právy Zakládat uživatele a Přistupovat do všech firem (nebo s administrátorským přístupem do firmy) může přidat do firmy uživatele z jiné firmy, i když nemá ve firmě zaškrtnuté Přidávat uživatele z jiné firmy. Platí to pro tlačítko v agendě Uživatelé i pro API (/c/{firma}/uzivatel/add a /c/{firma}/uzivatel/other-companies). Dříve API takový požadavek odmítlo hláškou „Přidávat uživatele není povoleno.“

Obnova zálohy firmy opět přijme zálohu, jejíž databáze obsahuje vlastní přepisovací pravidla (CREATE RULE) nebo pohledy místo systémových tabulek. Ve verzi 2026.6.0 se taková záloha odmítala. Pravidla i pohledy ve firmě po obnově zůstanou a firmu jde dál aktualizovat.

Obnova zálohy firmy hlídá volné místo na disku serveru před přijetím zálohy i během nahrávání. Když by po uložení zálohy nezůstalo volných alespoň 5 GB, server obnovu odmítne chybou 507 s hláškou, ve kterém adresáři je potřeba místo uvolnit. Firma nevznikne a dočasný soubor se zálohou se ze serveru smaže, takže se disk nezaplní.

Aktualizace databáze firmy už neběží s právy superuživatele databázového serveru, ale pod vlastní neprivilegovanou databázovou rolí. Obnova firmy ze zálohy a následná aktualizace jsou tak lépe chráněné proti podvržené záloze. Běžné zálohy se obnoví beze změny.

Sestavy Přehled stavu majetku a Přehled stavu majetku (se sumacemi za skupiny) ve formuláři Stav majetku k datu mají rozšířenou verzi. V ní se u majetku s účetními odpisy shodnými s daňovými (typicky drobný majetek) vyplní i účetní odpisy a účetní zůstatek a součty za skupiny odpovídají vytištěným řádkům.

Pracovní poměr se zaškrtnutým Zaměstnanec nenastoupil se už nenabízí ve výběru pracovního poměru u stálých mzdových složek, práce pro střediska, zápočtového listu, hlášení o ukončení pracovní neschopnosti a přílohy k žádosti o nemocenské. Jako výchozí se předvybírá jen poměr, do kterého zaměstnanec nastoupil. Hlášení REGZEC a PREZEC takový poměr nabízí dál.

Prodejní cena v ceníku zadaná ve webovém rozhraní se ukládá přesně tak, jak byla zadána. Dříve se cena bez DPH přepočítávala z ceny vč. DPH zaokrouhlené na haléře, takže se např. 0,333333 uložilo jako 0,33.

Volání API s neplatnou hodnotou parametru mode vrací chybu 400 s výčtem povolených hodnot místo chyby 500.

Zahraniční platby ve formátu MultiCash pro Komerční banku a ČSOB skládají adresu plátce, příjemce i banky příjemce podle pravidel dané banky. Dříve mohla banka adresu převést chybně, například jako město vzít název státu.

Měsíční hlášení (JMHZ) typu storno už nejde uložit s položkami. Uložení takového storna skončí hláškou „Storno podání nesmí obsahovat položky.“; storno bez položek se ukládá jako dosud.

Výpočet mezd už nekončí chybou, když má zaměstnanec v měsíci více pracovních poměrů a do jednoho z nich nenastoupil. Takový pracovní poměr se při výpočtu přeskočí.

U příjemky s upřesněním Příjem výrobku hlásila kontrola dokladu chybějící typ skladového dokladu i poté, co byl vybraný, a chyba zmizela až po dalším výběru. Nyní kontrola projde napoprvé. Když typ skladového dokladu opravdu chybí, chyba se hlásí u pole hlavičky Typ skladového dokladu, ne u položky.

Čtečka čárových kódů v desktopu přidá na doklad i položku, která vyžaduje typ skladového dokladu, a na typ se zeptá až při uložení. Dříve takovou položku odmítla.

Ukládání skladových dokladů ve webovém rozhraní už nekončí hláškou „Od otevření záznamu byl záznam změněn jiným uživatelem“, když s dokladem nikdo jiný nepracoval. Stávalo se to při inkrementálním ukládání, typicky po přidání položky výdejky ve firmě s oceňováním FIFO, kterou server při uložení přecenil, a u položek přijaté objednávky s automatickou rezervací. Odpověď na uložení přes API s as-gui=true nově vrací doklad i položky tak, jak jsou uložené v databázi, včetně ceny po přecenění.