Providing bookkeeping services is one of the activities that Poland's anti-money laundering law explicitly names as making a business an "obligated entity" (instytucja obowiązana). That brings extra duties toward the client, separate from anything GDPR covers — signing a bookkeeping agreement alone is not enough.
This page shows where that duty comes from, where AML ends and GDPR begins, what's worth recording when a new client comes on board, and what it looks like when a system keeps track of this instead of relying on one person's memory in the office.
The situation: a new client signs the agreement, and nobody raises the topic
A new client walks in, signs the bookkeeping agreement, hands over the company's registration documents and contact details. The conversation is about scope, pricing and deadlines — nobody asks who actually stands behind the company, where the funds it handles come from, or what the purpose of working with the office is.
That's not one employee's mistake — it's a gap in an onboarding process built around a civil-law contract and the data needed for GDPR, not around the fact that a business providing accounting services on a commercial basis is, by law, an obligated entity under anti-money laundering rules. Until someone names that gap out loud, it stays invisible — until an inspection, or a moment when someone has to explain why identification was never carried out at all.
An accounting office as an AML obligated entity
Poland's law on counteracting money laundering and terrorist financing, in Art. 2(1), lists a closed catalogue of entities treated as obligated entities. Point 17 of that catalogue covers, in plain terms, entities providing bookkeeping services on a commercial basis — with exclusions described in the act itself (AML act text, ELI).
It helps to see this in context: the same point of the catalogue, alongside accounting offices, lists — among others — advocates, legal counsels and tax advisors for the activities named there, plus real estate intermediaries. An accounting office isn't a special case here; it's one of many trust-based and financial-services professions the legislator considered sensitive enough for money flows to warrant extra duties, regardless of the specific contract with a given client.
Beneficial owner and the purpose of the relationship — what to establish upfront
In the practice of obligated entities, concepts such as the beneficial owner or the purpose and nature of the intended business relationship tend to accompany the client identification duty in this type of legislation. Exactly how to apply and document these concepts in a particular office, for a particular type of client, is worth settling with a tax advisor or a lawyer who knows the full scope of the act — this page doesn't replace that conversation, it just shows that the topic exists and where it comes from.
What this means in practice: procedures, not just a signature
Obligated-entity status means the bookkeeping agreement and its GDPR clause don't cover everything a client can reasonably expect from the office. The act imposes additional duties toward the client that go beyond the accounting service itself — which means it's worth having some repeatable procedure in the office, rather than relying on someone remembering to think about it.
A good practice is to separate two moments: signing the bookkeeping agreement (a civil-law act) from carrying out and recording client identification as an obligated entity (an act stemming from the AML law). If a team treats these as one and the same step, the AML identification quietly disappears in the shadow of the signature on the contract. Identification itself, as a decision, always stays with a person — what can realistically be handed to a system is tracking the deadline and sending reminders, not judging whether a given client raises concerns; we cover that split in more depth in Process automation in a company: what can realistically be handed over to a system and what cannot.
AML is not GDPR: two different duties toward the same client
It's easy to mix these two regimes up, since they concern the same client and often the same data — but they answer different questions. GDPR governs how personal data is processed: under Art. 5 GDPR, data should be adequate, relevant and limited to what is necessary for the purposes for which it is processed, accurate and kept up to date, and stored no longer than necessary (UODO, guidance on GDPR principles). That's the minimisation principle — an office shouldn't collect more client data than it actually needs.
AML asks a different question: who the client really is, where the funds it handles come from, and whether there are signals that the company is being used to launder money. Collecting more data about the origin of funds and the client's ownership structure isn't a minimisation breach here — it's fulfilling a separate statutory duty. This is exactly where automating client data flows, which we cover in a separate article, only applies partially: Automation and GDPR: where your customer data physically ends up describes the GDPR side of this topic, not the AML side.
The practical takeaway: if someone in the office says "we can't ask the client for more, because of GDPR," they're mixing up two regimes. GDPR limits data collection without a legal basis — and the obligated-entity duty is exactly such a legal basis for the scope of data that AML identification requires.
Who in a small office is responsible for identification
An office serving a dozen-plus companies rarely has a dedicated compliance role. That's normal at this scale — the question isn't "who has an AML job title," but who in the existing team is the point person that information about a new client reaches before bookkeeping for that client actually starts. Usually that's the office owner or whoever runs onboarding for new clients — what matters is that it's one named person, not an assumption that "someone will surely handle it."
Client documentation at onboarding: what's worth recording
Exactly what needs to be documented is something to settle with a tax advisor or lawyer, since it depends on the client's type and ownership structure — this page doesn't decide that. Regardless of the specifics, it's good practice for the fact that identification was carried out to be recorded somewhere at all: the date, who performed it, and what the outcome was — not just a verbal conviction that "we checked this when we signed the agreement."
Data minimisation: don't collect more than you need
The minimisation principle from Art. 5 GDPR cuts both ways: don't collect less than AML identification requires, but also don't collect more personal data "just in case" than you actually need for the purpose for which you're processing it (UODO, guidance on GDPR principles). Client identification records should have a clearly defined purpose — not turn, along the way, into a pile of extra data nobody can later justify.
Access to the client record in a CRM: who sees what
Once data from client identification lands in a shared system — CRM and automations bring phone, form, messengers and the Google Business card into one place — the question of who on the team has access to it comes up. Under Art. 29 GDPR, a processor and every person acting under the authority of the controller who has access to personal data processes it only on the controller's instructions (UODO, on authorisations to process data). The controller — in practice, the office owner — needs to keep control over who has access to client data, and to what extent.
Authorisations as an organisational measure, not a formality
Issuing written authorisations to process data is often treated as a formality — signed once and filed away. In practice, it's one of the organisational measures that actually let you enforce who should have access to which client record in the system (UODO, on authorisations to process data) — and that applies directly to data collected during AML identification, since it tends to be the most sensitive part of the whole client record.
A common mistake: identification "along the way," after the agreement is already signed
A common pattern looks like this: the agreement gets signed, the client starts using the service, and questions about the beneficial owner and the origin of funds only come up during an inspection or when a bank asks for extra documents. At that point, identification happens under time pressure, with a client who's already used to the relationship running without such questions — and who may read them as distrust rather than a standard procedure.
Reversing the order — identification as part of onboarding first, full service activation only afterward — costs one extra conversation at the start, but avoids a situation where you have to press a client, on short notice, for things that should have been settled months earlier.
Do it yourself: a client list and identification status
Before taking on the next new client, it's worth seeing where things stand in your existing portfolio:
- List every current client whose books you keep on a commercial basis.
- For each one, mark whether identification as an obligated entity was actually carried out and recorded — not just "whether the agreement was signed."
- For clients with no such record, decide who will run a follow-up conversation, and when.
- Record the outcome in one place, not in the memory of whoever happened to be handling that particular client.
- For new clients, build this step permanently into onboarding, before bookkeeping starts.
- Ask a tax advisor or lawyer whether the scope of what you collect is adequate for the type of clients you serve.
Before deciding to roll out such a mechanism at scale, it's worth seeing the real cost range for automation: How much does process automation cost in a company? 2026 ranges and what changes them.
For a broader look at what's worth automating in a small service business before tackling the next process, see Where to start automation in a small business: four thresholds instead of general analysis.
What it looks like when a system keeps track of this
Instead of relying on one person's memory, the whole process can run on a simple mechanism:
- 01new client
- →02CRM record
- →03identification checklist
- →04task for the responsible person
- →05reminder after a week
CRM and automations keep each client's record in one place, instead of scattered onboarding notes. Tasks turn "need to ask the client about the beneficial owner" into an actual entry with a deadline and a responsible person, so it doesn't disappear in a messenger thread. Where an office already uses a separate spreadsheet or an old client-tracking system, Integrations tie that data to the CRM instead of running two parallel lists. Customer Data keeps the onboarding history against one client card, so nobody has to search for who ran the identification and when.
Whether a particular client needs additional verification, and to what extent, is always a decision for a person — a tax advisor or a lawyer working with the office. The system's role is narrower: making sure that question doesn't get lost in the day-to-day flow of onboarding one client after another.
Frequently asked questions
Is every accounting office an AML obligated entity?
The act lists, in Art. 2(1)(17), entities providing bookkeeping services on a commercial basis as obligated entities, with exclusions described in the act itself. Whether a specific exclusion applies to your office is something a tax advisor or a lawyer familiar with the full scope of the provision should confirm.
What's the difference between the AML duty and GDPR obligations?
GDPR governs how a client's personal data is processed — under the minimisation principle in Art. 5 GDPR, adequately and no longer than necessary. AML asks a different question: who the client really is and where the funds it handles come from. These are two separate duties toward the same client, not one topic under two names.
Does obligated-entity status need to be reported separately when signing the agreement?
This page doesn't settle formal reporting steps — what formal steps follow from obligated-entity status in a specific office's situation is worth asking a tax advisor or lawyer about. The article shows where that status comes from at all, and why it's worth noticing when taking on a client.
Who in a small accounting office should be responsible for client identification?
Usually the office owner or whoever runs onboarding for new clients. What matters more than the job title is that it's one named person that information about every new client reaches before bookkeeping for that client starts.
Can data collected for AML identification be kept together with the rest of a client's data in a CRM?
Yes, as long as only people with proper authorisation can access it, in line with Art. 29 GDPR, and the controller — in practice the office owner — keeps control over who uses that data and to what extent.
What about long-standing clients whose identification was never formally carried out?
Start by reviewing the client portfolio and marking which ones have no identification record, then work with a tax advisor or lawyer on how to fill that gap retroactively in a way proportionate to each client's risk.