The most common question after sending an invoice is not "did I fill it in correctly" but "has the client actually seen it". Usually you answer it by hand: open the panel, open the invoice, read the activity timeline. Fifteen times a day.
Since 1 February 2026 there is a second source of anxiety: the response from KSeF (Poland's mandatory national e-invoicing system). An invoice rejected by the gateway is not a valid invoice, and you only learn about the rejection if something tells you. The rollout deadlines are published by the Ministry of Finance at ksef.podatki.gov.pl.
This article lays out exactly which events Biurko detects, which channels deliver them, and where the line runs between what the system knows and what it merely infers.
What Biurko actually tracks on an invoice
Every action on a document lands on the invoice activity timeline and belongs to one of five groups. The group doubles as a switch: you disable a whole category in one click instead of ticking twenty individual events.
Group What it covers Typical use lifecycle created, edited, deleted, duplicated, correction issued, corrected to zero, proforma converted, imported from KSeF, number changed who is touching the documents status issued, marked sent, status changed, the full KSeF path (queued, submitted, processing, accepted, rejected, failed, canceled, UPO retrieved, offline mode, outage, batch) is the document legally in circulation payments marked paid, marked unpaid receivables tracking documents email sent, delivered, opened, bounced, marked as spam, PDF downloaded, exported proof the client received it views invoice opened in the panel access audit inside the team
Repeat views of the same invoice by the same person within a short window do not create a new entry. Without that guard the timeline would read like a server log.
By default all five groups are on for in-app notifications. If you work alone and do not care who opened a document, switch off views and lifecycle and keep status and payments.
Three channels: bell, push, email
One event, three independent delivery paths.
The in-app bell. The entry lands in your notification inbox and appears without a page refresh. Biurko keeps a live realtime channel open, so if the panel is on your second monitor, the unread counter changes a second after the event. Notifications can be marked read one by one, in bulk, or cleared entirely.
Browser push. This is the "without logging in" part of the title. After a one-time browser permission you get a system notification even when Biurko is closed. Clicking it opens that specific invoice, not the dashboard. Push runs on the Web Push standard with VAPID keys, supports several devices per account, and turns off with a single switch.
Email. Reserved for things you cannot afford to miss: KSeF rejection, transmission failure, batch completion, expiring certificate. By default KSeF transmission emails are off and in-app notifications are on. That is deliberate. A business owner's inbox is crowded enough.
Every notification is rendered in the recipient's language, not the language of whoever triggered the event. In an accounting office where the bookkeeper works in Ukrainian and the business owner in Polish, one action produces two different texts.
Payments: what that notification really means
This part needs honesty, because competitors tend to blur it.
Biurko has no bank integration. It does not pull statements, does not match transfers to invoices, and does not know that a client has paid. A payments notification means exactly one thing: someone on your team changed the payment status in the system. Usually that is the bookkeeper working through a bank statement and ticking off settled items.
That is still useful, because in a team of two or three people the piece of information that gets lost is precisely "I have already checked this". But it is not automatic payment detection and it should not be sold as such.
Overdue status works differently, because it is computed rather than set. An invoice is overdue when it is not marked paid and its due date has passed. That is why "overdue" never appears as a manually assignable option: you only get "paid" and the undo.
is_paid = false AND payment_due_date < today -> overdue
is_paid = true -> paid
everything else -> unpaid
Biurko also does not send automatic payment reminders to your counterparties. Soft collections are on the roadmap, they are not in the product today, and we will not pretend otherwise.
Two status streams: KSeF and the client email
An issued invoice lives in two circuits at once, and each generates its own statuses.
The KSeF stream. A transmission moves through queued, submitted and processing, then ends in accepted, rejected or failed. You get a notification only on terminal states, because "processing" helps nobody. On rejection the notification body carries the error code translated into plain language rather than the raw gateway message. Channels are configured per event: you may want email on rejection but only the bell on acceptance.
A separate notification closes a batch send and shows the tally: how many documents went out, how many were accepted, how many rejected, how many need review.
The email stream. When you send an invoice to a client from Biurko, the mail provider reports four events back: delivered, opened, bounced, and marked as spam. Each lands on the invoice timeline and can trigger a notification.
A practical scenario: you send the invoice, a minute later you see "delivered", two hours later "opened". The client calls a week on to say they never received anything. You have the delivery timestamp and the first-open timestamp.
Two caveats worth knowing:
Opens are measured with a tracking pixel. Mail clients that block images, and privacy features such as Apple Mail Privacy Protection, will under- or over-count. A missing open does not prove the client did not read it.
Delivery is harder evidence. Bounces and spam complaints are harder still: the address then goes onto a suppression list so that further sends do not damage your domain reputation.
Biurko counts the first open, the last open and the total open count, resilient to duplicate and out-of-order provider events.
Who receives the notification
The rule is simple: the company owner and the invoice author, excluding whoever triggered the event. Nobody gets notified about their own click.
Notifications also reach current company members only. If a bookkeeper has left the office, they stop seeing data from invoices they once created.
Accounting offices get one more switch. When a bookkeeper files an invoice with KSeF on a client's behalf, the document's author is also informed of the outcome by default. That can be turned off if the client does not want twenty notifications a day about operations they do not control anyway.
Certificate warnings run on a separate track. A daily check at 08:00 sends a warning 7, 3 and 1 day before the KSeF certificate expires, each threshold with its own switch. An expired certificate stops your sending, so this is not the one to disable.
Setup checklist
Enable browser push on the device you actually work on. One account handles several devices.
Keep the
statusandpaymentsgroups on. They answer "is the document valid" and "do we have the money".Switch off
viewsif you work alone. That group only earns its place with several people in the company.Turn on email for KSeF rejections and transmission failures. Leave acceptances on the bell.
Do not disable certificate warnings. Three thresholds is the minimum to renew in time.
In an accounting office, agree with the client whether they should receive copies of transmission notifications, and set it once.
Come back to the settings after a week. If you are not reading something, turn it off. A notification you ignore is worse than no notification.
Summary
Notifications only earn their keep when they answer a specific question and do not drown you in everything else. That is why Biurko groups events, separates channels, and sets defaults so that email is reserved for situations that demand a response.
An invoice rejected by KSeF, an email that bounced, and an expiring certificate are the three things you need to know about the same day. The rest can wait for the bell.
Create a free account at biurko.io and configure notifications around the way you work. It takes less time than one manual status check.
FAQ
Will Biurko notify me when a client pays an invoice? Not automatically. Biurko has no bank integration, so the "paid" status is set by a person. A payments notification tells you that someone on the team changed that status. Overdue status, by contrast, is computed automatically from the due date.
Will I be notified if KSeF rejects an invoice? Yes. Rejection is a terminal transmission state, so the notification always fires, with the error code translated into plain language. It goes to the in-app bell by default; email and push are enabled separately in settings.
Can I see whether the client opened the invoice I emailed? Yes, if the documents group is enabled. Biurko records delivery, first and last open, and the open count. Bear in mind that image blocking and mail privacy features distort open statistics.
Do push notifications work when I am not logged in? Yes. After a one-time browser permission, notifications arrive with the app closed, and a click opens the specific invoice. One account can hold several active devices, and push turns off with a single switch.
Can I mute notifications from my clients' accounts in an accounting office? Yes. Each of the five event groups has its own switch, and KSeF transmission notifications are configured per event and per channel. You can also stop forwarding transmission outcomes to the invoice author.