Security and data
Your Polish entity's ledger sits inside this platform. You choose where the platform sits.
SimplyTax is not a pass-through that forwards a file and forgets it. The platform stores the data the file is built from: journal entries, general ledger accounts and the trial balance. That is the complete financial record of the entity, so asking where it is held is a fair question, and it is not one that a certification badge answers.
The answer begins with a decision that is yours rather than ours: our cloud, or an installation inside your own infrastructure. Both are delivered today.
On-premise or cloud — both are real deployments
This is not a choice between a product and a roadmap item. Both installations exist and both are maintained. What differs is whose team carries the work, and that is the part worth settling before anyone signs.
On-premise
The platform runs inside your infrastructure. Accounting data does not leave it in order to reach us. The only thing that leaves is what has to reach the authority anyway: the finished file, submitted when someone on your side approves it.
Backups, availability, OS patching and the maintenance window for a platform update are then yours. That is a real cost, paid every year, and we are not going to describe it as a detail.
Cloud
We run the environment: availability, backups, and the platform update that follows a schema change. Nothing new appears on your infrastructure diagram and nothing new lands on your IT department's backlog.
In exchange, the accounting data sits in the vendor's environment. That should be accepted deliberately rather than discovered in an annex, which is why it is written here in the same size type as everything else.
On-premise is not automatically safer. It is safer when you have a team that takes backups and has restored one at least once. Without that team, running it yourself moves the risk rather than reducing it — and a group controller is usually better placed to judge that than the local finance office is.
Access to the source system is read-only
The translator reads and writes nothing back. It does not create accounts, post entries, amend documents, add fields or tidy data on the way through. Your finance system behaves exactly as it did before the platform was connected, which is also what makes the connection reversible.
When something the structure requires is missing from the data, that shows up in the check — and the correction is made where every other correction is made: in the accounting system, by the person responsible for it. This is a decision rather than a technical limit. The single version of the truth stays on your side.
The access itself is often narrower than a database read. An export to a file, to SFTP, or produced by an agent running on your own network requires letting nobody into the database at all. Which route applies depends on what the source system can hand over.
What the platform holds, and why it needs it
The platform is not stateless. It keeps the data because the filing has to stay reproducible: someone will ask what exactly was submitted for a given period, and by then the source system will be in a different state. The list below is the reason for each item, not a feature summary.
| Data | Why the platform holds it |
|---|---|
| Journal entries and general ledger accounts for the reported period | The file is built from them. A correction filed a year later has to be rebuilt from the same data, not from a fresh export out of a source system that has moved on since. |
| The trial balance | Part of the same structure. Held together with the rest of the period so it stays possible to show exactly what went to the gateway. |
| The fixed asset register | The fixed asset structure describes each asset and its history. That data cannot be reconstructed backwards if it was not captured at the time. |
| Taxpayer master data, held separately per entity | The header of a file must match the entity it is filed for. With several Polish entities in one group this is the most common source of a wrong filing. |
| Generated files and their status | The history carries three states: generated, submitted and awaiting the UPO, accepted. Without it nobody can say where a given period actually stands. |
| The reference number and the downloaded UPO | This is the evidence of filing. It is what a tax inspection asks for, and what group audit asks for — usually long after the period was closed. |
What it does not hold: anything outside the agreed export scope. That scope is fixed during implementation and written down, rather than decided at each run. The data specification sets it out field by field.
The audit trail, and how long it has to survive
A file that passes validation proves that its structure conforms to the Ministry's schema, and nothing more. The evidence of filing is the reference number and the downloaded UPO — the Polish authority's official confirmation of receipt — archived next to the file, per period and per entity. A submission is closed only when that confirmation is in the archive.
Polish tax records have to be retained for years set by Polish law, and an inspection asks about a period that closed long ago. So "can we still get at this in three years" is a requirement, not a nicety — and it is the requirement that most quietly fails, because nobody tests it until the day it matters.
What can be reconstructed later, for one period and one entity
- the file exactly as it was generated, viewable as XML in the platform rather than only as a download
- that it was checked against the Ministry's official XSD schema before it was sent, not after a rejection came back
- the reference number the gateway returned for the submission
- the status the period currently stands in: generated, submitted and awaiting the UPO, or accepted
- the UPO itself, downloadable from the archive
Validation and acceptance are shown as two separate steps, because they are two separate things. A structurally correct file can still be rejected for reasons that have nothing to do with the data — most often the authorisation of the person filing. We would rather show both steps than describe the outcome.
Where the evidence chain does not close
Reporting to the National Bank of Poland works differently from filing with the Ministry of Finance, and it is worth saying so rather than drawing one tidy diagram for both. The platform generates the NBP forms; it does not submit them. A user uploads them to the bank's reporting portal manually, authenticating with a certificate the bank issues.
The bank returns no equivalent of a UPO. So the only record of what was sent and when is the one that stays on your side, and a correction to an earlier submission has to be documented by the filer. In the platform the generated file keeps exactly that status — generated — and we do not attach a confirmation nobody issued.
Several entities: separated, not pooled
Each entity has its own taxpayer master data, its own file history and its own UPO archive. The company switcher changes which entity you are working in — it does not merge two entities into one view, and it does not let one entity's data be filed under another's name.
What does not exist: a consolidated status board for the whole group, one screen showing every entity at once. If a vendor offers you that screen, it is not a description of this product as delivered today. For a group with several Polish subsidiaries this is usually the first thing asked, so it is better said here than discovered during implementation.
Who at the vendor can see what
The honest answer here is structural rather than procedural, because a procedure can be rewritten in a week and a deployment model cannot. In an on-premise installation the vendor has no standing access to your environment: access exists when you grant it, for as long as you grant it. In the cloud deployment the vendor operates the environment, so technical access on the vendor's side exists — claiming otherwise would be untrue, and the first reviewer to ask would find it.
The named roles, how support access is recorded, and the procedure for granting and revoking it are contractual commitments. They belong in the agreement, where they carry weight, not on a page that can be edited in five minutes.
One distinction that a vendor review often merges: a user account in the platform is not an authorisation to file. Under Polish law the right to sign and submit on behalf of an entity comes from a power of attorney filed with the tax administration, not from a setting in an application. The platform cannot create that right and does not claim to.
What this page does not settle
Some answers are missing here on purpose. Not because they are awkward, but because they are commitments rather than marketing copy. A web page changes with one commit. A schedule to a contract does not.
- the infrastructure provider and the processing location for the cloud deployment
- the list of sub-processors and how changes to it are notified
- the data processing agreement and the terms it is signed on
- retention periods, and how data is returned or deleted when the contract ends
- certifications held and the results of security audits
- the support access procedure for a customer environment
Each of these is answered in writing during procurement, in a form your legal or information security function can file and rely on later. If a vendor answers questions like these only with a web page, that is not an answer — and it is the same standard we expect you to hold us to.
Who processes this data
- Controller
- SimplyMobilePlus Sp. z o.o., ul. Prezydenta Gabriela Narutowicza 40/1, 90-135 Łódź. Data enquiries: sales@simplymobileplus.com.
- Purpose
- To answer your enquiry and, if it goes that way, prepare a quotation.
- Legal basis
- GDPR art. 6(1)(b) — steps prior to entering a contract — and art. 6(1)(f), our legitimate interest in commercial correspondence. We do not ask for marketing consent, because answering an enquiry does not need it.
- Retention
- Up to 24 months from the last contact; if a contract follows, for the period required by accounting law and limitation periods.
- Recipients
- Our mail and hosting providers, acting on our instructions. We do not sell this data and do not transfer it outside the European Economic Area.
- Your rights
- Access, rectification, erasure, restriction, portability, and objection to processing based on legitimate interest. You may also complain to the President of the Polish Personal Data Protection Office.
- Is it required
- No. Providing data is voluntary, but without an email address we have no way to reply.
Send us your vendor security questionnaire — we answer it item by item →
Contracts and correspondence are with SimplyMobilePlus Sp. z o.o., registered in Poland; registration details are in the footer and can be verified without us. This page describes the handling of a Polish entity's accounting data and makes no statement about obligations outside Poland, and it is not tax advice. Data collected by this website — the contact form — is a different set entirely and is described in the privacy policy.