v0.140.0 — Fixes and improvements

Declarations that match what you see. A declaration for a period that has not started yet can be neither generated nor filed, and filing a period before it ends requires confirming that you will have to correct it; the declaration page opens on the last finished month. A JPK draft prepared before the tax settings were completed has to be regenerated first — you file exactly the file and the amounts you see.
Months without active VAT payer status. The Overview no longer suggests a JPK_V7 for a month in which the company is not an active VAT payer, and the VAT registers do not show purchases or sales from such months — they say why the register is empty. The automatic filing settings no longer claim that a declaration is waiting to be prepared for a company without active payer status, and the calendar does not show a withdrawn obligation for a month with a blocked draft.
Declaration list, status and deadlines. The status of a filed declaration shows the sending day and whether it was on time, instead of “overdue” counted from today; the declaration list has pages, and the year, form and status filters cover all of the company’s declarations. Labels of entries on the Overview timeline follow the frequency of the filed period (monthly or quarterly), not the current profile. The “KSeF readiness” card counts only documents that need a KSeF number. The JPK deadline on the invoice list, the dashboard and the revenue widget is the same nearest filing deadline as in the calendar — a company that does not file JPK_V7 that month gets no deadline. The JPK_V7 deadline does not appear until you save the tax profile, and a month that has already been filed is no longer counted down. A declaration that again disagrees with the register after being aligned asks for a correction once more, and a prepared correction draft no longer claims it is unnecessary.
JPK files. In JPK_V7 a Polish contractor NIP is written as digits only, even when it was entered with dashes, spaces or a PL prefix; a sale with a settlement period has one tax point — the end of the period; JPK_FA shows a correction invoice issued in Biurko with the correction amount (the difference), not the amounts after the correction.
VAT filing settings. The tax settings no longer accept quarterly filing in the first 12 months after registering as an active VAT payer (art. 99 sec. 3a of the VAT Act) — they name the first allowed quarter, and companies with quarterly filing saved earlier see a warning. The cash method means quarterly declarations (art. 99 sec. 2 of the VAT Act), so the cash method with monthly filing after that period is also refused, naming the quarter from which declarations are filed quarterly; when we do not know the registration month, Biurko reminds you of the rule and asks for it.
JPK_V7 correction with a large overpayment. A correction resulting in an overpayment above PLN 10,000 asks for a written justification of the reasons (art. 81 § 2b of the Tax Ordinance) and stores it in the correction file; without it the correction will not be sent.
NBP rate and the rate in “Register entry”. When NBP does not respond or the table for the right day is not yet published, we do not substitute a rate from another day — a purchase with self-assessment waits for the table, and the declarations for that month wait with it; the invoice and purchase forms show the reason for the refusal next to the rate field. You declare the rate always together with the day from which it applies, only where the KSeF file does not give the rate along with the VAT in zloty, and only until a correction has been issued for the invoice; fetching the invoice from KSeF again does not overwrite it, and corrections and copies use the right rate, without pairing a new rate with an old NBP table.
No rate — amount unknown. The tax calendar, the declaration list, the timeline, the Overview and the totals above the invoice list no longer count a foreign-currency document without a rate as if it were in zloty — they say the amount is unknown, and the chart shows a labelled gap; the “Products” widget ranks only by known amounts.
Statistics, widgets and charts. The statistics of the invoice list, the dashboard and the widgets count VAT and foreign-currency amounts the same way as the VAT register and the KSeF file — each rate converted to zloty separately, a correction as the difference at the rate of the corrected invoice; a foreign-currency purchase fetched from KSeF takes the tax in zloty straight from the invoice, and editing it does not overwrite it. Dots on the invoice list chart carry the colour of their series, the chart tooltip no longer shows hidden series, and the average per document in the “Invoices” widget names its currency. The “Products” widget does not count revenue twice for a paper issued outside Biurko after a correction from KSeF. The “Products” widget counts foreign-currency sales revenue to the grosz the same way as the invoice list — also for corrections issued in Biurko — and says how many sales imported from KSeF are not assigned to any product and for what amount; its title on the dashboard is no longer cut off. On the dashboard, the number of invoices next to a contractor has the correct form (1 invoice, 2 invoices, 5 invoices), and the number of a foreign contractor is not labelled “NIP”.
Purchase register: deduction period and export. For a purchase settled on payment, you can name the deduction period only after the whole invoice is paid and no earlier than the month of that payment — until then the VAT is deducted by itself in the month of each payment. The period cannot point to a month in which the company is not an active VAT payer, and the register warns about a period later than the rules allow and no longer warns falsely for an unpaid invoice with only a payment date. The export covers the same documents as the VAT register, including RR VAT invoices and their corrections with the refund; next to the document amounts it shows the amounts that the JPK_V7 register deducts, does not repeat an invoice with a declared deduction period, and without given dates covers only the invoices the register has included up to today.
Cash method and corrections. A correction to an unpaid invoice no longer reduces the VAT twice — payment of the amount after the correction settles the whole transaction, and “Left to pay” takes the correction into account; a payment added on the correction page is recorded on the corrected invoice, so the invoice and the correction show the same payment state, and a purchase reduced by a correction that arrived before the deduction month lands in the register together with that deduction. A payment covering several invoices is split between them by net amounts, and the VAT of a purchase corrected several times in a month and of a sale with a correction agrees to the grosz with the payment in the register. A correction that moves an export to an intra-Community supply of goods lands in the register in the month of the correction, the same as in the summary information.
Payments counted together with corrections. Payment filters, receivables and arrears, paid revenue on the dashboard and the “Paid” column in the export count an invoice together with its corrections — a correction to a paid invoice does not show up as overdue, and an invoice corrected to zero is not a debt; a correction fetched from KSeF that corrects an earlier correction is counted together with the invoice it concerns, and the “Correction invoices” list also shows corrections of corrections and collective corrections.
Bad debt relief. A payment dated before the declaration with the write-off was filed works like a payment entered with that date, and the filed declaration of that month gets a “needs correction” mark; an increasing correction is not reported a second time and does not get lost when the payment date is moved, and when the declaration with the write-off was not accepted, Biurko withdraws the increasing correction too; an invoice correction that reduces the debt restores part of the write-off, corrections across several months add up to the grosz, and for a collective correction Biurko proposes no write-off for any of the invoices it names and warns when one of them already has a bad-debt-relief correction filed.
Corrections issued in Biurko. You cannot issue a correction dated earlier than the last issued correction of the same invoice; a correction draft cannot be re-pointed to a purchase invoice, a draft or an advance invoice; the next correction to a KSeF correction issued outside Biurko is issued where the earlier one was issued; a foreign-currency invoice correction first needs the rate of the original invoice, and a “before” value that matches no line does not reach the file — the form asks for a fix. The correction printout shows the lines before and after the correction, and the VAT table, the summary and the amount in words give the correction amount. A second draft correction to the same invoice ends with a message giving the reason, and you cannot issue a correction of an advance invoice that reduces the advance below the amount settled in settlement invoices — the settlement invoice has to be corrected first. A second correction to a settlement invoice is no longer refused as exceeding the advance.
Corrections from KSeF. A correction fetched before the invoice it corrects links to it when the invoice arrives; a collective correction that lowers a line price imports correctly; a correction loaded from a file dated earlier than a correction issued in Biurko does not change its amounts. Documents created from an invoice fetched from KSeF — a correction, a copy, an invoice from a proforma — are treated as issued in Biurko: they can be sent to KSeF, and a purchase copy can be edited and deleted. A seller’s correction loaded from a file after two corrections from KSeF, the second of which corrects the first, is settled only by its own difference. Importing from KSeF a correction to a correction of a settlement invoice is no longer refused as exceeding the advance. A correction to an advance invoice issued outside Biurko that reduces the advance below the amount already settled is flagged with a warning in the register. A purchase correction entered by hand for an invoice covered by a collective correction from KSeF no longer overstates the deduction in the register.
Flat-rate revenue register: settlement invoices. A second correction to a settlement invoice no longer understates the revenue in the flat-rate register, and an advance in a foreign currency settled by a final invoice is converted at the rate — before, it was counted as if the amount were in zloty. Filed declarations do not change.
A reason for the refusal instead of a generic error. When issuing, converting a proforma, changing a number or payment status, or deleting a purchase from KSeF cannot be done, the message gives the specific reason: the simplified-invoice limit exceeded (counted at the new invoice’s rate), a missing rate, a missing advance or corrected invoice; a payment higher than the amount due says how much is still left. A purchase named by any correction cannot be deleted — neither singly nor in a batch — and the message gives the number of that correction; likewise, you cannot delete an advance on a purchase that has been settled by a final invoice, and the message gives the number of that invoice.
Two people, one invoice. A page opened for another company says so plainly — another company is now active and nothing was saved; a record deleted in the meantime is named, and a draft issued, edited or deleted by someone else at the same moment ends with a message instead of a silent change or an invoice vanishing from the list. When switching to your own company that has been deleted in the meantime, Biurko says the company is deleted, not that you have no seat in it.
Numbering and document history. A sales number takes its month and year from the issue date on the document — an invoice dated in the previous month gets the next number in that month’s series; the number on a draft is the one the invoice will get on issue, and the starting number on the numbering card suggests the number of the next invoice, so saving at the start of a month leaves no gap. Corrections, duplicates and invoices from a proforma name the person who created them as the issuer, a proforma’s history says which invoice it was converted into, and every event in the history, including sending to KSeF, has its own icon; amounts in notifications, history and e-mails are written in the reader’s language, with the currency.
RR VAT invoices — issuing. The invoice suggests the flat-rate refund rate set for the company (6.5% or 7%), calculates the refund amount itself from the net value and the rate, requires a unit of measure on every line and does not accept an acquisition date later than the issue date; it can be issued collectively for a month of continuous deliveries, and the amount in words reaches KSeF in the invoice currency. A purchase invoice can no longer be saved as an RR VAT invoice — such a document is issued by the buyer of agricultural products, so in Biurko it is created under sales.
RR VAT invoices — corrections, currency and import. A correction opens with the rate of the corrected invoice, the next correction takes the rate of the last one, and the refund in zloty for a foreign-currency invoice is converted once for the whole document — the same on the printout, in the register and in JPK_V7; the printout says “Acquisition date” and calls the refund the flat-rate refund rate, not a VAT rate. An RR VAT invoice fetched from KSeF lands in sales with its KSeF number, its refund and acquisition value come straight from the document, and an invoice issued by another taxpayer in which the company appears as the farmer does not fall into purchases or JPK_V7 — the import skips it and states the reason. The print of an RR VAT invoice correction that changes the rate (e.g. from 7% to 6.5%) shows two rows — before and after, each at its own rate. RR VAT invoices fetched from KSeF show the refund amount from the document on every line.
Phone, tablet, screen reader and keyboard. Tall dialogs fit on a phone screen: the content scrolls while the title and the save button stay visible, and the close button is easier to hit with a finger; a bank account number in the bank account list fits on one line, the “Unit” and “Quantity” fields in an invoice line are wide enough, the month column of the tax calendar is narrow with the duties visible beside it, and the declaration step summaries are readable on a tablet too. Date fields and the calendar are read out in the app’s language, icon-only buttons have a name, and the date of the registry answer next to a contractor’s status can be read by touch and keyboard; a person with view-only access to contractors opens the contractor dialog read-only. The Biurko AI window shows missing lines, an incomplete list of lines and a mismatched check digit as separate warnings with a description, and a long account number and a long seller name are fully visible on a phone as well. The state of the KSeF connection in company settings is described in words on a phone, not only by colour. A long invoice number no longer runs off a phone screen, and the payment-date chip on the invoice page does not overlap the bank account details. The button that expands a group of events in the activity list is easier to hit with a finger, and the full name of the AI invoice reading window is visible when you hover over the title.
Invoice list and form. The “issued by” filter on invoice lists no longer shows internal person numbers, and the “Mark as paid” window does not suggest tomorrow’s date to people in another time zone. The VAT summary and the total on the RR VAT invoice form, and the order value with tax, are calculated the same as on the saved document — with each line rounded to the grosz. The KSeF number field on the invoice page refreshes when the number changes elsewhere, and a refresh of the page by someone else’s action does not lose the place you are at on the keyboard. On the invoice list the header shows which period the total covers (the current month or the chosen date range), and the chart is labelled with the calendar year instead of “Last 12 months”.
Dates, numbers and small screen fixes. “Not later than today” messages give a concrete date instead of the English “today”, date limits are written as in the rest of the app (DD.MM.YYYY), Ukrainian date messages no longer confuse the allowed limit with the disallowed one, an empty month field shows “mm . yyyy” without overlapping characters, and the exchange rate and the NBP table day on the invoice page are written in Polish. Status badges in the “Tax office” frame look like the rest of the app, and the frame says the filing deadline has passed; a contractor from outside the EU or without an identifier no longer has a registry badge that nobody asked about; the “Mark as paid” dialog for a tax speaks about the tax, not the ZUS contribution; on a purchase invoice page the company NIP in the buyer card carries the label “NIP”; the link from a tax settings message leads straight to the right field, and an unsaved change does not disappear after the jump. The amount in words on the print has the correct grammatical form of the currency in every document language (e.g. “jedna hrywna”, “dwie hrywny”). A contractor with a foreign number has the status “not subject to checking”, with no check date, instead of “not registered”. Captions on the invoice page are no longer smaller than readable, and the document history uses the application’s colours. The interface language you pick no longer reverts after a page refresh when another request was still in flight at the moment of the change.
Invitations, search and messages. A double click on “Accept” in a company invitation no longer ends in an error, and accepting an invitation to an account address that is being deleted, or two invitations at once to the same new address, ends with a clear explanation; searching lists does not depend on letter case, and the company list finds a company by a fragment of its NIP; warnings about KSeF certificates expiring reach every company; errors in the import console and on the sending screens are described in a plain sentence, and the import screen says why it does not know the number of invoices yet instead of showing zero; a contractor’s VAT status does not change after an empty or unreadable registry answer. Certificate-expiry warnings do not concern deleted certificates, and the import console does not write “ready” when the statistics could not be read and shows a failed search for invoices. The contractor list refreshes the VAT status by itself when Biurko finishes checking on the white list, and shows the check day. The KSeF import time is stated unambiguously, e.g. “2 min 5 s” instead of “2m”.
KSeF: no answer. When KSeF does not respond for a longer time, sending ends with “KSeF did not respond” rather than “too many attempts”, and a request limit or a server error gives its own reason; the connection test and certificate login give the reason in Polish and do not spoil a working connection; one company exceeding the request limit no longer holds up the import for others.
KSeF: uncertain sending outcome, number and UPO. When KSeF breaks off the answer to a sending, the invoice is not marked as failed or sent a second time — it waits to be checked, and the message says where to check it; the same after a brief failure to save on our side. “Ask KSeF again” finds a sending that got no answer and fetches its number, and when KSeF does not have it — sends the invoice again with no risk of a double filing; you can also enter the KSeF number from the KSeF Taxpayer Application, and Biurko checks that it matches the invoice. When KSeF treats an invoice as a duplicate, Biurko takes over the KSeF number and the UPO of the first sending; the number of an invoice with no established outcome cannot be changed, and a manual KSeF number fix accepts only a number issued to this seller and catches typos. An invoice accepted by KSeF keeps its KSeF number in the VAT register and in the JPK file even when the UPO could not be fetched at once during a KSeF outage; the acceptance time shows the exact moment given by KSeF — also for invoices sent in a batch and imported ones.
Batch sending. A batch sending broken off halfway is not marked as failed — the batch waits to be read or checked, and its invoices cannot be sent a second time by mistake; an invoice from a batch has the KSeF verification code on the printout like an invoice sent singly. Re-sending a rejected invoice sends it in its current form, an invoice with an attachment goes in a separate session, an invoice cancelled and renumbered during sending does not get the KSeF number of the document sent under the old number and does not hold up the others, and an invoice that KSeF did not list after the session ended does not stay in “sending” — it goes to be checked. The reason a document in a batch was rejected and a refusal detected by Biurko are shown in the language of the person reading them, not of the person who sent the batch. Sending a batch that contains a proforma invoice no longer ends in an error — the invoice is refused with an explanation, and the other documents of the batch go on. The KSeF batch list counts rejected invoices once — the total matches the number of invoices in the batch, and on the batch page the full error message of a rejected invoice is visible in full, also on a phone.
Offline invoices (KOD I code). The number of an invoice issued in offline mode with a printed KOD I code cannot be changed, so paper, screen and KSeF show the same number; re-sending such an invoice after cancelling or after a failed sending passes the same document to KSeF with the same code the buyer holds, also after the submission deadline has passed. When KSeF rejected the document itself, Biurko points to a technical correction instead of sending a second document — such a correction can be re-sent, and once it is accepted Biurko proposes no next one; an offline invoice with an attachment reaches KSeF correctly, and the printout of an invoice sent online does not carry a code signed OFFLINE until KSeF accepts it.
Sending a declaration — uncertain outcome. When sending a declaration or a JPK file breaks off midway, we no longer say “nothing was filed” or “cancelled”: a sending that may have reached the Ministry cannot be cancelled, and Biurko asks you to check in e-Urząd Skarbowy and record the result — it does not release the period for sending again. The same applies to a file signed with a trusted profile, a file accepted when saving the confirmation on our side failed (we save it later), and a file regarded as a duplicate of an earlier sending, which we record as filed together with its UPO; the archive keeps exactly the file that reached the Ministry. The notification about a failed sending gives the reason in your language.
A period after a statement, and filed outside Biurko. Withdrawing the “nothing arrived” statement restores the “needs correction” mark and the bad-debt corrections, so a later payment of the invoice returns the deducted VAT again; the withdrawal is refused while a later correction awaiting its result stands above the period, and when the Ministry confirms the file after the statement, we record the period as filed together with its UPO. Switching to quarterly filing does not cancel a monthly declaration whose result we are still waiting for; a period whose file may already have reached the Ministry is protected like a filed one, and Biurko points to a JPK_V7 correction when an invoice in the filed file carries the BFK mark even though KSeF has already given it a number. A period filed outside Biurko before its end can be marked as filed — with the real day and the UPO; refusals to withdraw such a mark, and to mark a period with a file awaiting its result, are explained in plain words.

Cookies