Accounting-office software: client portal, KSeF, e-Deliveries
You are not buying a VAT engine. You are buying one client file that does not vanish between mail, WhatsApp and a USB stick. Accounting-office software is a portal, a workflow and a mailbox — not another ledger.
The owner of an accounting office with 80, 200 or 400 client files does not wake up thinking about “digital transformation”. They wake up thinking that client X’s invoice sits in the bookkeeper’s WhatsApp, client Y’s PIT-11 scan sits on a USB stick, and a letter to company Z arrived in a mailbox nobody opened because the person with the password is on sick leave. You are not buying a VAT engine. You are buying one client file that does not vanish between mail, WhatsApp and a USB stick. Accounting-office software in that sense is not another financial-accounting programme. It is the layer where the client, the document, the status, the power of attorney and the deadline live in one place — and Optima, Symfonia, Enova or Rewizor stay where they have been posting the books for years.
This text is written for partners and owners of bookkeeping offices and tax firms, not for a software-house marketing deck. GESOFT — Paweł Matusiak, Laravel, Vue and Android — does not sell a “better ledger”. If Comarch, InsERT or Sage already give you an e-file the client can actually log into, buy that and do not build your own. A custom accounting-office client portal makes sense when you have several sites or several brands, an unusual workflow, a field representative with a phone, or an integration the vendor will not open. What follows is a decision map, not a slide about artificial intelligence that “will post the invoice by itself”.
The difference you will not see on a licence price list shows up in April and in January. In April an attachment vanishes, the client swears they “sent it on Tuesday”, and the return sits because nobody can say whether the file entered the folder. In January a letter from an authority vanishes because it arrived in the company’s e-Deliveries box, not the office inbox. The ledger programme is fine in both stories. What breaks is the layer in front of the ledger: intake, status, escalation, role, a trail. That is the product this article is about.
An office with 80 files can still “somehow remember” who sends to Ania’s number and who brings a folder once a month. An office with 250 files no longer remembers — and that is when the partners start shopping for another ledger, even though their Optima or Symfonia is not sick. The intake is sick. If after the opening paragraphs you feel your pain is “we do not have AI postings”, this text is not for you. If you feel the pain is “we do not know whether March is complete”, you are in the right place.
We do not promise that a portal “takes statutory liability off you”. The Accounting Act is blunt: the office keeps the books under a contract, but the liability of the client’s head of unit does not disappear because someone uploaded a PDF to a cloud. A system can watch whether a document arrived, who accepted it and by when an answer is due. It cannot pretend to have replaced the head of unit or to have issued a tax opinion. A portal that tells the client “in our view you may deduct” walks into reserved activities that PKD 69.20.A does not open by itself. We will come back to that.
How many “offices” there are — COIG, GUS and three subclasses instead of one 69.20.Z
The worst slide you will get from a list broker or from a platform “for every bookkeeping office in Poland” starts with “there are X accounting offices in the country”. X depends on what someone counted. From 1 January 2025 PKD 2025 applies — Council of Ministers regulation of 18 December 2024 (Journal of Laws item 1936). The old subclass 69.20.Z split into three: PKD 69.20.A bookkeeping and accounting activities, 69.20.B tax advisory, 69.20.C financial audit. Anyone who in 2026 still says “offices are 69.20.Z” is quoting a classification that no longer exists.
Those three letters are not decoration on a CEIDG extract. They are a map of the market and a map of risk. An office that keeps books, registers and settlements under a contract sits in PKD 69.20.A. A tax adviser who issues opinions and represents before authorities in the scope reserved by the Tax Advisory Act sits in 69.20.B — and that is a regulated profession. A statutory auditor and an audit firm are 69.20.C. You may hold more than one subclass in one entity if the law and your licences allow it. You may not pretend that a portal with an “advice” checkbox turns A into B.
COIG’s list dated 12 May 2026 sells a commercial extract of 17,348 entities labelled “bookkeeping and accounting activities”. Mazowieckie: 5,220 (30.09%). Warsaw: 3,648. That is a commercial extract, sold as a contact database. It is not a GUS census. It is not the number of “offices operating in Poland this month”. We will not give you the sentence “according to GUS there are X offices”, because we have not opened such a table for this text. The gap between a commercial extract and official statistics is not an academic nuance. It is why you do not plan an IT budget from “a share of a 17-thousand-entity market”.
For a systems decision the national figure is less important than yours anyway. How many files you actually run — not “how many tax IDs sit in a 2019 spreadsheet”, but how many contracts are alive. How many of those files are KRS companies, how many sole traders, how many communities, how many farmers, how many lump-sum taxpayers. How many clients send documents every day, and how many once a month in one ZIP at 23:40. How many already have an e-Deliveries box, how many still do not. How many have been issuing invoices in KSeF since 1 February 2026, and how many join on 1 April 2026. You build the system from that list, not from the average in an address broker’s file.
- PKD 69.20.A — bookkeeping and accounting: books, registers, settlements under a contract. Not a tax opinion.
- 69.20.B — tax advisory: a regulated profession, reserved activities. A portal is not an adviser’s stamp.
- 69.20.C — financial audit: another regime, another liability, another product.
- COIG 17,348 as of 12 May 2026 — a commercial extract, not GUS and not “that many offices operate”.
- Mazowieckie 5,220 / Warsaw 3,648 in that extract — concentration, not “your competitors one for one”.
- Your own file count, client types and document channels — the only X that matters in a portal quote.
The National Chamber of Tax Advisers has long repeated a point that “software for offices” marketing likes to blur: do not confuse a bookkeeping office with a tax adviser. Accounting services were deregulated in 2014. There is no “Ministry of Finance certificate” as a condition of running an office — anyone who sells you that as an entry ticket is selling a myth. Tax advisory remained a regulated profession. Reserved activities sit in the Tax Advisory Act, not in a SaaS price list. Accounting-office software must carry that distinction in roles, in reply templates and in what the client is not allowed to click as “the office’s opinion”.
What an office may do — and what a portal must not pretend to be
An office under PKD 69.20.A keeps, under contract, accounting books or a tax revenue-and-expense ledger, registers, social-security and tax settlements, and prepares reports to the extent the contract and the law allow. The client — the head of the unit — does not shed liability for the reliability of the books because they “gave it to the office”. The contract sets the scope, document-delivery deadlines, fees and termination. The system should turn that contract into file states, not into terms nobody reads at login.
A tax adviser may do what an office must not do on its own: reserved activities, including opinions, representation in the statutory scope, signing certain filings. If your entity has an adviser — good. Then the role in the system must be hard: that person sees and signs a different set of documents than the bookkeeper on a revenue-and-expense ledger. If you have no adviser, the portal must not produce sentences that look like an opinion. “According to the calculator in module X the deduction is…” is not a feature. It is professional risk dressed as a button.
A practical test worth running at a partners’ meeting before anyone buys an “advice module”: take the last five emails in which a client asked “may I…”. How many replies were a bookkeeping act (we will post it this way, this code, this deadline) and how many were an opinion (this is how we read the rule, this is how I would defend it, this is what I advise in a dispute)? The first stays in the file and in the status. The second — if at all — goes through a person with a licence, with a date, a version and a disclaimer that it is not an automaton. An accounting-office client portal that answers both kinds of question with the same chatbot looks pretty in a demo and expensive after the first audit or the first complaint.
- Allowed: take a document, set a status, watch the JPK/VAT/CIT/PIT/ZUS calendar, show the client gaps, prepare a pack for signature.
- Allowed: run an accounting document workflow from the client inbox to import in the ledger and back — with a who, when, what trail.
- Allowed: handle powers of attorney, KSeF tokens, e-Deliveries box rights as a process, not as “a password on a sticky note”.
- Not allowed: pretend to be a tax opinion, an interpretation or representation if you have no title to it.
- Not allowed: write in the UI that the system “approved the settlement” instead of “the document arrived, waiting for the bookkeeper”.
- Not allowed: keep one “office” login for five people — that breaks both accountability and the processing agreement.
The same applies to a law firm that sits next to the office, or is the office with a second plate on the door. A law-firm CRM watches matters, court deadlines and time. The bookkeeping file watches the period, the source document and the settlement status. Those are two products with a shared client, not one screen called “matters and VAT”. If you run both practices, split roles and retention. Court files should not live in the same inbox as fuel-invoice scans just because “it is the same Kowalski”.
The client contract is the system spec, not a PDF annex
A good office contract says: what the client delivers, by when, in what format, what happens if they do not, what the office returns, in what time, who signs, how extra work is priced (corrections, summonses, audits). Good accounting-office software takes those sentences and turns them into file states: “purchase invoices for March missing”, “waiting for UPO”, “JPK to sign”, “KSeF power of attorney expired”. A contract that lives in a drawer, while the bookkeeper invents statuses in their head, ends in “but I sent it” and an hour of thread-hunting. The system will not replace a bad contract. It will show that the contract is bad — and that is already value.
KSeF 2026 as an operational tsunami — receiving from February even when the client issues from April
The National e-Invoice System hurts an office not because XML is hard. It hurts because the process splits in time. The official timetable on ksef.podatki.gov.pl: the duty to issue structured invoices from 1 February 2026 for taxpayers whose 2024 sales including tax exceeded PLN 200 million; from 1 April 2026 for everyone else. Receiving invoices in KSeF is mandatory already from 1 February 2026 — including for a client who themselves only start issuing in April. An office that “will wait with the portal until Q2 because small taxpayers issue from April” leaves the purchase file empty for two months.
The legal base is the Act of 5 August 2025 (Journal of Laws 2025 item 1203) and the FA(3) schema. B2C is optional. There is an Offline24 mode. Until the end of 2026, sales documented by invoices up to PLN 10,000 a month may stay outside KSeF; the duty to quote the KSeF number in payments is deferred; receipts with a tax ID up to PLN 450 may serve as simplified invoices until the end of 2026. Those are time-limited exceptions, not a strategy for an office with 400 B2B clients. A shop client with a handful of invoices may stay on the simplification. A wholesale company may not. Your accounting document workflow must know which client is in which regime, not have one “import XML” button.
The most expensive office mistake of 2026: treat KSeF as “pasting XML into Optima”. The client must grant the office rights. A token, a profile, a power of attorney, a scope (read, issue, self-billing), an expiry date, the person on the client side who confirms it, the person on the office side who runs it when the first is on holiday. When the token dies mid-period, the file goes silent. When one certificate sits on a partner’s USB stick, that partner’s illness is an outage for the whole portfolio. That is a process, not a weekend integration. Technical detail for a panel that itself issues is in KSeF in a company application. Here the point is the office as attorney for many taxpayers.
- List clients: who already issues in KSeF from 1 February 2026, who from 1 April 2026, who uses the PLN 10,000 exception, who is B2C only.
- For each tax ID: does the office receive, issue, or both; which token / which right; expiry; a deputy.
- Inbound path: fetch, match to the file, status “to post”, exceptions (foreign tax ID, duplicate, a correction without an original).
- Outbound path: document source (ledger, client panel, the office issuing on behalf), KSeF number, UPO, status back on the file and on the accounting-office client portal.
- Offline24 and an outage: a queue, who decides to go offline, who sends the next working day — not “somehow in mail”.
- Corrections and duplicates: the same path, not a spreadsheet named “corrections_march_v3”.
- Revoking the right when the contract ends: that day, not “we will remember at the next JPK”.
Inbound from 1 February 2026 changes a junior bookkeeper’s day more than any new ledger screen. Until now the client sent a PDF or a photo of a till roll. Now some invoices will not arrive by mail at all. They will arrive in KSeF. If the office has no process for receiving on the client’s behalf, the purchase file is holed and JPK_V7 is built from a set nobody closed. If the office has a process but no status on the file (“14 documents received, 2 unmatched, 1 correction without an original”), the bookkeeper still phones. A portal that shows the client the same figures cuts those calls. The ledger will not show that to the company’s owner at 22:00.
An attorney, not “a shared login to the National System”
The ministry did not design KSeF so that an office logs into the client’s account with the owner’s password. Rights exist so you can account for who did what on behalf of which taxpayer. The office system should hold: the right identifier, the scope, the period, the responsible person, an operation log (fetch, send, schema error), a ban on secrets in a “Downloads” folder on the reception shared Windows box. When the client leaves, revocation is a termination checklist item, next to returning paper files and disabling the portal login. If that is missing you do not only have an IT problem. You have a processing-agreement problem and a confidentiality problem about documents that are no longer yours.
Not every client needs the office to issue sales in KSeF. Many issue from their own wFirma, Fakturownia, Subiekt or a shop panel. The office then receives and posts. Others want the sales invoice to leave the office ledger. Still others have their own vertical system and need a bridge. Accounting-office software does not pick one of those roads for everyone. It keeps which road applies on the file and does not let anyone drop a PDF “just in case” when the document already has a KSeF number. A double truth (XML in KSeF, PDF in mail, a manual copy in the ledger) is more expensive than no system.
e-Deliveries for KRS clients — this is no longer “a topic for October 2026”
An e-Deliveries box is not a gadget of the “digital state”. It is a channel that carries a letter with a deadline. The timetable on biznes.gov.pl: new firms registered in CEIDG or KRS from 1 January 2025 take an address at registration; KRS entities from before 2025 — from 1 April 2025; CEIDG from before 2025 — from 1 October 2026. If you serve KRS companies, you should already have a client-box process. Not from October. Not “when the ministry reminds us”. Since April 2025 that channel at companies is alive — or it is dead on a password one person knows.
A typical failure we hear over coffee, not at an implementation workshop: the company’s president gave the login to the bookkeeper “because they handle the letters anyway”. The bookkeeper left on holiday. The deputy does not know the password. A summons sits. The deadline runs. The office learns from a client who got a phone call from the authority, not from the system. That is not the fault of e-Deliveries. It is the fault of the “one password on holiday” model. The system needs roles: who monitors which client’s box, who escalates after X hours, who may read, who only sees that something arrived, what cover looks like, where the trail is that a letter was accepted. One “office@” account on twenty tax IDs is convenient until Friday. On the Monday after a long weekend it is expensive.
- The client’s ADE address stored on the file, not in a sheet named “boxes_2025”.
- A monitoring role and a deputy role — by name, not “someone from the companies team”.
- Escalation: no read within the agreed time → an alert to the file owner and the duty person.
- Classification: for accounts / for the client / for the adviser / for the law firm — not everything is JPK.
- A reply deadline as a dated task, not a star in the inbox.
- A ban on sharing the box-admin password; revocation the same day a staff member leaves.
- Sole traders: a calendar for 1 October 2026, box onboarding as a contract point, not a Facebook post from the office.
The office itself is also an entity. Your own box (KRS or — in due time — CEIDG) is a separate process: your contracts, summonses to you, correspondence with the tax office and ZUS in your own affairs. Do not mix it with client boxes in one “all unread” view. That is the same error as a shared Outlook for three companies and the office. e-Deliveries in a product for an office is a module of boxes with roles, not an “integrate ePUAP” button. The technical integration is a means. Roles are the end.
What the system should do with a letter it does not understand
Not every PDF from the box is an invoice and not every summons is for the bookkeeper. Some letters go to the client’s board (KRS, a court, the labour inspectorate), some to payroll, some really to the VAT file. An accounting document workflow ends badly when everything falls into one “to post” queue. The queue should be able to say: I do not know whose this is and whose it should be. Then a human decides once, and the system remembers the rule (“letters from this sender at this tax ID → role X”). Learning that on 400 files without rules is a full-time job. With rules — an exception.
The client portal: invoice, status, a question, a power of attorney
An office client does not want “an app”. They want to know three things: did I deliver what I was supposed to; does the office see it; do I have to sign or pay something. An accounting-office client portal is the answer to those three questions at 22:00, without a call to the bookkeeper’s mobile. If the portal shows a different truth than the file in the office, the client goes back to WhatsApp and the portal dies in a month. One truth or no portal. That sentence matters more than the button colour and more than whether you start with a PWA or a native Android app.
Invoice upload is the simplest screen and the most common place a project dies. The client photographs crookedly, twice, with no tax ID, at night, from a spouse’s phone. The system should take the file, put it in a period, show a thumbnail, and refuse “sent on Messenger to Ania”. OCR can help. It is not a condition. The condition is that the file is in the folder and that the bookkeeper sees a gap queue instead of hunting across four channels. If the client already drops the document into KSeF, the portal shows that it arrived by another road, and does not ask for a second scan of the same invoice.
File status is not a green “all OK”. It is a list: period documents, gaps, open questions, deadlines (VAT, JPK, ZUS, CIT, PIT, the financial report), items to sign, powers of attorney with an end date, KSeF rights, the e-Deliveries box. A client-president sees a summary. An in-house bookkeeper at the client sees a file queue. An attorney sees what their contract covers. A company partner who is not on the contract with the office does not see payroll. Roles on the client side are as important as roles in the office. Without them the portal is a leak dressed as UX.
- Named logins, 2FA for people who see payroll and full books — not a shared password “Kowalski2024!”.
- Upload to a period and a type (sales, purchases, a bank statement, payroll, other), not a general “drop zone”.
- Document status: accepted / in query / posted / rejected with a reason.
- A question to the office on a specific file or period — a thread, not a new email “about that invoice”.
- Powers of attorney and tokens: text, scope, date, a scan, an alert before the end.
- A calendar of the client’s duties (“statements by the 5th”) and the office’s (“JPK by the 20th”) — as in the contract, not a Facebook meme.
- A phone app: a responsive portal is enough at the start. Native Android when a representative or a field client actually lives in it.
Questions in the portal replace the worst genre of email: “sending again, I do not know if it arrived”. A thread on a document has an author, a time, an attachment and a close. The bookkeeper does not search Sent. The client does not send a third version. If the question needs a reserved opinion, the system does not suggest an answer from a language model. It suggests: hand to the adviser role or refuse in this channel. That is a feature, not a gap. The market is full of demos in which a chatbot “helps with VAT”. After an audit it helps the client’s lawyer.
Powers of attorney, UPL-1, KSeF and the box — one shelf, not four folders
In a living office a power of attorney dies more quietly than an invoice. A date ends, the board changes, someone revokes a UPL-1 and nobody updates the list at the tax office, and the office still “signs” because that is how it was last year. An accounting-office client portal should show the set: the contract with the office, tax powers of attorney, KSeF rights, access to e-Deliveries, contact consents, the scope of the processing agreement. An alert “X ends in 30 days” is cheaper than a summons you cannot take up. This is not a sales CRM. It is a CRM of authority.
Workflow: mail and WhatsApp kill the VAT deadline more quietly than a bad ledger
A financial-accounting programme breaks rarely. An accounting document workflow breaks every day. The client photographs an invoice over coffee and sends it to a private number because “it is faster”. The bookkeeper is at another client’s till or on a video call with the tax office. The file sits on a phone. The period closes. JPK goes without that purchase, or with that purchase in the next month because someone rushed it into the wrong bucket. Both sides blame “the system”. The culprit is the lack of one intake.
Mail is not bad as a fallback channel. It is bad as the only archive. A thread has ten people in CC, three versions of an attachment and a subject line “FW: FW: scan”. WhatsApp is worse: copies on private phones, no retention, no role, no proof that the office accepted the document in the contract sense. A USB stick once a month is the most honest of the three — at least you can see that someone arrived — and the worst under KSeF, because some documents no longer have a physical form you can “bring in”. One file inbox, many channels falling into it, zero channels that bypass it. That is the whole philosophy of the workflow.
- Intake: the portal, mail to a file address (not to a person), a scan at the office, inbound KSeF, optionally a client API.
- Registration: period, type, sender, a hash (to catch a duplicate), a thumbnail, who accepted.
- Queue: the file’s bookkeeper sees only theirs; the lead sees team backlog; the client sees “delivered / in query”.
- Query: the question goes back to the client on the file; until there is an answer, the document does not pretend to be posted.
- Posting: import or an entry in the ledger; a “in the books” flag returns to the file. The ledger stays the source of the accounting entry.
- Period close: a gap checklist, a client confirmation (“I have no more purchases”), only then JPK as a status, not as content.
- Archive: retention from the contract and from the rules, not “we keep everything because disk is cheap”.
The VAT deadline does not die in the tax engine. It dies in the gap between “the client thinks they sent it” and “the office thinks they got it”. A system that closes that gap is worth more than another report in the ledger. The ledger report will say what was posted. The portal will say what is missing. An office with 200 files lives on the second sentence. You already have the first in Optima.
Count conservatively, without a productivity slide. If two bookkeepers together lose even a few hours a day on “did it arrive / it did not / send it again / wrong period”, that is not the cost of “a lack of innovation”. It is the cost of not having one file inbox. An accounting document workflow does not have to be pretty. It has to be the only one. A second channel that bypasses the file is more expensive than no portal — because then you have two truths and one return.
WhatsApp can be civilised; it cannot be made into a file. If the client will absolutely not enter the portal, a gateway: an office service number, automatic filing of the image into the working period, a confirmation “accepted into file X, March, purchase”, a ban on further substance in that channel. That is a prosthesis. A prosthesis is better than an infection. Do not sell it as a strategy. The strategy is the portal and a file address. The prosthesis is a transitional month for a president who “does not click links”.
The period checklist is the product, not the lead’s spreadsheets
Every mature office has, in a head or in a sheet, a list: statements, sales, purchases, cash reports, payroll, mileage, fixed-asset notes, balance confirmations, declarations. Accounting-office software should hold that list as a template per client type (revenue-and-expense, full books, lump sum, a community, a farmer) and as a state per period. The lead does not collect Friday statuses on Slack. They see red files. The client sees their gaps, not your internal queue. You file JPK_V7 and JPK_KR under the current finance-ministry regulation — the system watches the calendar and the status (“prepared / signed / sent / UPO”), not the content of the return. We do not guess 2026 schema-amendment dates here. The duty calendar is configuration data, not a built-in sermon.
GDPR: the office is a processor; the processing agreement is not “a blog download”
In the typical layout the client (a company, a sole trader, a community) is the controller of their contractors’, employees’ and partners’ data. The office is a processor: it processes that data in order to perform the bookkeeping contract. GDPR Article 28 requires a processing agreement. Not “a clause in the portal terms”. An agreement: subject, time, nature, types of data, categories of persons, duties, sub-processors, deletion or return at the end, audit. If you host the portal with GESOFT or another software house, a chain appears: client → office → vendor. Every link must be on paper, not in an assumption.
Data that enters the file is not “newsletter contacts”. It is invoices with contractor data, payroll, sick notes, social-security medical findings, account numbers, national ID numbers, sometimes health data. That is data for which a shared login is not only sloppiness. It is a breach of accountability: you cannot say who opened the payroll. Roles: the file’s bookkeeper, payroll, the lead, a partner (supervision, not a view of every salary “because it is my firm” — an office partner is also under minimisation), IT support without document content. Retention: after the contract ends you do not keep payroll “just in case they come back”. The return-and-erase path is in the contract and in the system. More on application mechanics: GDPR in web applications.
- Controller: usually the client. Processor: the office. Sub-processor: portal hosting, email, SMS, OCR — a list in the contract, not “we use various clouds”.
- A processing agreement signed before the first file hits the server, not “with the next annex”.
- EU hosting, encrypted backups, a restore test, a ban on private Dropboxes “because it is faster”.
- Access logs for payroll and full books; an alert on an unusual export.
- A ban on a shared password; 2FA; immediate disablement after someone leaves.
- Portal: the client corrects their own contact data; they do not download someone else’s payroll because “I am on the board and curious”.
- A team instruction: WhatsApp with a client invoice is an incident to civilise, not “the normal mode”.
An incident in an office rarely looks like a hacker film. It looks like a bookkeeper who sent the wrong employee’s PIT-11 to the wrong client because Outlook suggested a similar name. Or a trainee who pulled “everything for the month” onto a USB stick to work at home. A system that makes mass export hard and sending from the file to the right contact easy is a control, not a whim. A processing agreement without such controls is a PDF. The authority does not read your price list. It reads whether obvious leaks were foreseeable.
Secrecy and subcontractors: who else sees the file
Offices hand files “for cover” to another office, use external payroll, a parent office in a network, a ledger cloud, OCR in Asia, a helpdesk that “will just pop in”. Each of those entries is either a sub-processor or a separate controller — a lawyer qualifies that, not a programmer. The system must be able to cut access, limit a file, log an entry. A franchise network that gives HQ one login to every field office is building a structural leak. Your own portal under your brand is sometimes cheaper than explaining someone else’s HQ.
Integration with Optima, Symfonia, Enova, InsERT — a bridge, not a weekend chart-of-accounts rewrite
Rewriting the chart of accounts, contractor cards and posting history “into our modern ledger” over a weekend is a fantasy sold by people who have not closed a year. An office with 200 files has years of analytics, patterns, cost circles, VAT dictionaries and JPK settings in the ledger. That value is larger than any portal. Integration means: the document and the status go into the ledger or out of it on a known path (an API, a file exchange, a robot at a desk, an import the bookkeeper approves). It does not mean: “from Monday you post in our module”.
Realistic variants, cheapest first: (1) the portal and workflow live beside, the bookkeeper posts as today and ticks “in the books” on the file; (2) import of source documents into the ledger (PDF/XML/KSeF) mapped to the file; (3) a return from the ledger: is the period closed, did JPK go out, does the contractor have a balance; (4) a real API if the vendor and the licence allow it. Each step up costs analysis, not “a marketplace plugin”. In the meeting we ask: which version, which ledger implementation partner, is there an API, who on your side can export the contractor dictionary. Without those answers an integration quote is fortune-telling.
- Source of the accounting entry: the ledger. Source of “did the document arrive”: the portal / workflow.
- Do not duplicate the contractor card “for beauty”. One ID, a bridge, conflicts (two tax IDs, typos) on a report, not in silence.
- KSeF: often more convenient if send and receive go through the stack that already has the certificate — the ledger or an integrator — and the portal holds the status and the right.
- Payroll: if it lives in a separate module (Płatnik, Optima HR, Symfonia Kadry), we do not drag it into the portal “because GDPR anyway”. We drag the status and the source files.
- Test on a copy of the database, not on production on the Friday before JPK.
- A contract with the Comarch / Sage / InsERT partner: who maintains the bridge when they change the schema.
Some offices want to leave the vendor. That is a separate, expensive ledger-migration project, with a certified accountant, a parallel year, liability for the report. GESOFT does not pretend to do it “while we are at the portal”. If an offer says “we will move you off Optima in a month and throw in KSeF”, ask who will sign the opening of the books. You are not buying a VAT engine. You are buying a file that does not vanish. That sentence protects a budget better than a discount on licences.
What a bridge can break if you design it badly
The usual mines: importing the same invoice twice from KSeF and from a scan; overwriting a manual ledger correction with an automatic portal status; a contractor created twice (once from the invoice tax ID, once from the card); a period “closed” in the portal and open in the ledger, or the reverse; an API password stored in a script on the desktop. A bridge with no idempotency and no human on exceptions is more expensive than no bridge. At the start we prefer a “to approve in the ledger” queue over silent magic. Magic looks good in a presentation. Exceptions are your Tuesday.
SaaS (wFirma, Fakturownia, Saldeo, Taxxo, Comarch e-file) versus your own
The market is not empty. wFirma and inFakt cover micro-clients who want to click themselves. Fakturownia issues sales. Saldeo, Taxxo, Next and similar live on OCR and a flow into the office. Comarch and InsERT add an e-file and a messenger next to their ledger. Sage has its own world. There are franchise networks with a shared panel. If one of those products closes your pain — buy it. Demand an export, a processing agreement, data location, and that the client sees your brand or at least does not see an advert for a competing office after login. GESOFT is not at war with Saldeo. It runs projects Saldeo will not take.
Your own accounting-office software starts to pay in a few hard cases. You have more than one brand or more than one office and you do not want the client logging into a nationwide SaaS with someone else’s logo. You have a workflow the template does not know: a representative who collects documents at the client and needs offline Android; or a network in which a file travels between offices; or clients with their own systems (wholesale, medicine, a developer) that should push files by API, not by mail. The vendor will not give you that integration, or will give it at a price that eats the file’s margin.
SaaS is cheaper at the start and more expensive on exceptions. Your own system is more expensive at the start and cheaper when the exception is your business. An office that lives on standard revenue-and-expense ledgers and lump sums rarely needs a build. An office that lives on 80 full company books, payroll, KSeF as attorney and e-Deliveries boxes often needs at least its own layer: a portal under its domain, roles, a contract calendar, a bridge. Not a whole ledger. A layer. That distinction saves six months of partner argument.
- Stay on SaaS when: one site, typical files, the client accepts their app, the vendor e-file works, you have no unusual API.
- Build a layer when: brand, several offices, the field, roles SaaS does not have, integrations, retention and logs under your contract, not their terms.
- Do not build a “better Optima”. That is another budget, another liability, another team.
- A SaaS licence with no file export is a trap — you test the export before a year in the new tool.
- A “per file / month” SaaS price at 300 files can exceed the instalment on your own portal. Count on your numbers, not ours.
An honest conversation both sides avoid: some offices buy their own portal for ego (“we have a system”). Ego does not pay the maintenance invoice. Maintenance is updates, backups, duty cover, changes in KSeF and in the boxes, training a new bookkeeper. If you do not have in the company a person who owns the product — even half-time on the substance — SaaS with vendor care is more reasonable. GESOFT hands over code, documentation and a warranty. It does not hand you an IT department in the MVP price. We ask that in the first meeting, not after the invoice for stage two.
What GESOFT builds — and what it deliberately does not
GESOFT is Paweł Matusiak: Laravel and Vue applications, Android where the field needs it. For a bookkeeping office and a tax firm we assemble an operational layer. The core: the client file (contract, books type, people, roles, powers of attorney). An accounting-office client portal under your domain and brand. Upload and a queue. Period status and a checklist. Questions on the document. A duty calendar from the contract, not from a universal “deadlines in Poland” that drifts from the regulation. KSeF as a process of rights, inbound/outbound and statuses, with a bridge to whatever already issues or receives. e-Deliveries as boxes with roles and escalation. A phone app for the client — web first, then native Android if there is a real reason.
What we do not build “while we are here”: a VAT engine, JPK as the content of a return, a Płatnik replacement, an Optima replacement, a chatbot tax adviser, an office marketplace, “find a bookkeeper” leads. We do not write tax opinions in code. We do not claim OCR will eliminate the bookkeeper. OCR, if at all, is help on the queue, with a human on the exception. We do not promise that in the first sprint a hook to every Enova version “already works, we will just switch it on”. Integration is a stage after a map of your ledger.
- Analysis: how many files, which ledger, which channels today, KSeF already or not, KRS boxes already or not, who is the data controller.
- MVP: the file + upload/status portal + office roles + a processing agreement in the hosting contract. Without that there is no production.
- Workflow and the period checklist. Month-end is visible before a pretty dashboard is.
- KSeF and e-Deliveries as processes — rights, queues, escalation — not as a logo on a slide.
- A ledger bridge in a scope you can maintain. Exceptions on the table, not in a log.
- Phone: a PWA or Android for a concrete role (client, representative), not “an app in the store because the competition has one”.
The stack is deliberately dull. Laravel on the API, policies and queues. Vue in the office panel and the portal. A database you can back up and hand over. Android when offline and the camera are daily life, not decoration. Code in Git, documentation, six months of warranty on the delivered scope. EU hosting. The same approach we use on other vertical panels: register and status first, ornaments later. An office is not an exception to that rule. It is its sharpest test, because a deadline will not wait for a sprint review.
A tax firm gets the same blocks with a harder adviser role: a note that does not go to the client automatically; a pack to sign; a split between the bookkeeping file and a dispute file. If you also run court or recovery matters, we do not mix that with the invoice flow — we rather connect it to the logic we described for a law-firm CRM. Shared: the client and the login. Separate: retention and secrecy.
A phone app is not the first milestone
A client who will not enter the portal in a browser will not enter a Store app either; they will only have one more channel to ignore. First one URL, a login, a drop, a status. A home-screen icon (PWA) covers 90% of “we want an app”. Native Android makes sense when an office representative walks companies, photographs documents, works in a hall with no signal and needs an offline queue. Or when a field client (service, a site) lives on a phone and will not sit at a laptop. Then yes — Kotlin, the camera, sync, a ban on saving to a private camera roll. Not on the day you sign the portal contract.
A checklist for the office partners’ meeting
Before you write to anyone — to us or to a SaaS vendor — sit for an hour in your own group. The list below is a meeting agenda, not a marketing brief. Whoever answers these points on paper will not buy a slide. Whoever does not will buy a slide and implement it in JPK season.
- How many files are actually alive and what is the mix (revenue-and-expense, full books, lump sum, payroll, communities, farmers)?
- Which ledger (Optima, Symfonia, Enova, Rewizor, InsERT, other) and does it stay?
- Where does a document enter today: personal mail, a shared inbox, WhatsApp, paper, the vendor e-file, KSeF?
- How many clients are already under the duty to issue KSeF (the 200 million threshold / 1 February 2026), how many from 1 April 2026, how many only in receipt from February?
- Is the office a KSeF attorney? Where do the tokens live? Who covers the person with access?
- How many KRS clients have a living e-Deliveries box? Who reads it? What happened on the last long weekend?
- Do you have signed processing agreements with clients and with cloud vendors? A sub-processor list?
- Has the Comarch / InsERT / Saldeo / Taxxo e-file been tested by a client, not only by you — and what does it lack?
- Do you need your own brand, several sites, Android in the field, APIs from client systems?
- Who in the company will own the product after go-live (a name, not “the team somehow”)?
- Which period must not be touched by an implementation (January, April, July — write your own hell)?
- What must work in 90 days, and what can wait a year? One file truth comes before a pretty dashboard.
If after that list the answer is “we stay on the vendor e-file and civilise the channels” — stay. Really. Implementing discipline (one address, no WhatsApp, powers of attorney in a calendar) is cheaper than code and often removes 70% of the pain. If the answer is “the vendor will not take our workflow / brand / field / bridge” — then we talk about a layer. Not about replacing the ledger. About a layer.
A quote will not fall out of a catalogue “portal for an office from X zloty”. It will fall out of the number of roles, the number of bridges and whether KSeF and e-Deliveries sit in stage one or stage three. More truth on the way in means fewer annexes. That works both ways: if after an hour it is clear that wFirma plus channel discipline is enough, we will say so. We would rather lose a project than maintain a system nobody opens because the bookkeepers went back to WhatsApp in week two.
Frequently asked questions
- Will accounting-office software replace Optima, Symfonia, Enova or InsERT?
- No — and it should not, if those programmes post your books. GESOFT builds a layer: a client portal, a workflow, file status, KSeF and e-Deliveries processes. The ledger stays. A bridge — after a map of versions and APIs, not “we will rewrite the chart of accounts at the weekend”.
- How many bookkeeping offices are there in Poland?
- We do not say “according to GUS there are X”, because we have not opened such a table. COIG on 12 May 2026 sells a commercial extract of 17,348 entities labelled “bookkeeping and accounting activities” (Mazowieckie 5,220, Warsaw 3,648). That is not a GUS census and not how many offices operate. From 1 January 2025, 69.20.Z became 69.20.A, 69.20.B and 69.20.C. For a quote your file count counts, not an address list.
- Does an office need a Ministry of Finance certificate?
- No. Accounting services were deregulated in 2014. Do not invent “an MoF certificate as a condition of running an office”. Tax advisory (PKD 69.20.B) is a regulated profession with reserved activities. A portal does not replace an adviser’s licence.
- From when does KSeF hurt an office, if small taxpayers only issue from 1 April 2026?
- Receiving invoices in KSeF is mandatory already from 1 February 2026. Issuing: 1 February 2026 if 2024 sales including tax exceeded PLN 200 million, 1 April 2026 for the rest. An office as attorney needs rights, tokens and queues before “the small ones start issuing”. Source: ksef.podatki.gov.pl, the Act of 5 August 2025, FA(3).
- Do e-Deliveries only hit sole-trader clients from October 2026?
- CEIDG from before 2025 — the duty from 1 October 2026. But KRS companies from before 2025 have it from 1 April 2025, and new firms from 1 January 2025 at registration. An office with companies should already have a box process with roles, not one password on holiday. Source: biznes.gov.pl.
- Who is the data controller — the office or the client?
- Usually the client is the controller and the office the processor. A processing agreement (GDPR Article 28) is mandatory. Special-category data (payroll, ZUS health) needs roles, retention and a ban on a shared login. If you host the portal with us we are a sub-processor — that must be on paper.
- Saldeo, Taxxo, Comarch e-file — why build our own?
- If they close the workflow and the client logs in — buy that and demand an export and a processing agreement. Your own when you have several offices or brands, an unusual workflow, Android for a representative, integrations the vendor will not give, or the data and the code should stay with you. We do not build against a package on principle.
- May the portal advise the client on a VAT settlement?
- It may show status, gaps, the calendar and what is already in the files. It may not pretend to be a tax opinion or an interpretation. Reserved activities stay with the adviser. A chatbot “advising on VAT” is a risk, not a feature.
- Do we need a Google Play app at the start?
- No. A responsive portal and maybe a PWA are enough for the file to stop vanishing. Native Android when the field and offline are daily life for a representative or a client. A store icon does not close the month.
- What should we write in an enquiry to get a quote, not a survey?
- File count and the books mix, the ledger name and whether it stays, whether you are a KSeF attorney, whether company e-Deliveries boxes are alive, what the current e-file lacks, whether you need your own brand or Android. Form: /kontakt. We will say whether to build or to buy a package.
Describe your project