Privacy Policy
Muntin Systems GmbH
1. Who we are and what this policy covers
Muntin Systems GmbH (“Muntin”, “we”, “us”) holds a register of the legal entities a customer runs, ingests each entity's payroll register for each period, maps it onto one fixed row contract using a column mapping proposed by a fine-tuned classifier and confirmed by an operator, runs a fixed set of cross-entity reconciliation checks, including identity matches proposed by an embedding model, and holds the period open until every exception has been cleared by a named person. On lock it posts a payroll journal per entity into the customer's ERP, fires headcount and cost center webhooks, and freezes an immutable period record. We do not calculate pay, we do not compute or file statutory deductions, we do not move money, and we do not issue payslips.
Registered at Katharinenstrasse 17, 04109 Leipzig, Germany.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | The entity register, the payroll registers you place in Muntin, the headcount and cost center data derived from them, and the operator accounts you name | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus 6 years, to cover legal claims and accounting rules.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
Almost everything in this service is personal data about your employees, and none of it is ours. Salary, employer cost, deductions, dates of birth, the last four digits of a bank account and the entity a person is employed by are yours as controller, and we hold them as your processor on your written instruction. Two other things matter here and are easy to overlook. The first is that our checks are cross-entity by design, so a record from one of your entities is compared against records from another, and you should satisfy yourself, and your works council where you have one, that this is within your own lawful basis before you load anything. The second is the exceptions log: who cleared which exception, and when, is a record about your own staff as well as about the data, and it is retained because the value of a locked period is that it can be shown to have been cleared by a person.
B.1 What we handle, and in what role
Account data, meaning your work email, your entity, your billing contact and the operators you authorize, we hold as a controller. The entity register, every payroll register you load, the mapped rows, the exceptions and their resolutions, the journals we post and the webhook payloads we send, we process as your processor, on your instruction, for as long as the subscription runs.
- The entity register. Each registered legal entity you operate, its registration number, incorporation date, pay calendar, currency, the payroll system or bureau that runs it, and its cost center tree. This is a description of your corporate structure and we treat it as commercially confidential: it is never published, never aggregated into any coverage or benchmark statistic, and never disclosed to any payroll provider or bureau.
- The payroll register, per entity, per period. The file as you supply it and the rows we map from it: employee identifier, cost center, gross, employer cost, statutory deductions, other deductions, net, currency and pay date. We keep the source file byte for byte alongside the mapped rows, because a posted journal has to be traceable to the file it came from.
- Matching keys. To decide whether two rows in two entities are the same person we read name, date of birth, role and the last four digits of the bank account. We hold no full bank account number, no national identifier, no tax identifier, no absence reason and no health data, and we ask you not to send them. If a file arrives carrying a field we do not need, it is dropped at mapping and not stored.
- Operator accounts and the exceptions log. Who you authorize, what each of them cleared, what they changed, and when. This is the evidence that a locked period was cleared by a person rather than skipped, so it is written on every action and cannot be edited by anyone, including us.
We hold no payment instrument for your employees and we initiate no payment. The file that pays people leaves from wherever it leaves today, and nothing in Muntin is on that path.
Do not load absence reasons, medical certificates, disciplinary records or anything else that is not on a payroll register. We hold no lawful basis for them and no place to put them, and if one reaches us we delete it and tell you in writing.
Our ERP credential is a service user you issue, scoped to posting journals and reading the chart of accounts. We ask for nothing wider and we will refuse a broader scope if you offer one.
B.2 What we do with it
Everything stays in Frankfurt. Ingestion, mapping, the reconciliation checks, both models in service, the identity index, the exceptions queue and the locked period records run on cloud infrastructure in Frankfurt, supplied by the provider named on our subprocessor list. The column classifier is retrained on Microsoft Azure in Germany West Central, also in Frankfurt. No processing of any kind happens outside Germany.
The two model corpora are governed differently. The column corpus, which holds a header string and a statistical fingerprint of the column with no cell values, mapped to a field name, is shared across the service. The identity corpus, which holds pairs of payroll rows and a decision about whether they are one person, is employee personal data and is partitioned per customer, never pooled and never used to train anything that touches another customer's account. The column corpus is the only one used on Azure, for training the classifier; the identity corpus is never used there.
A locked period is never edited. Once a period locks, its mapped rows, source files, check results and clearance record are immutable. A correction is a new period version carrying a reason and an author. The superseded version stays readable and is marked as superseded, because a journal that was posted from it is in your ledger and has to remain explainable.
Your data is not compared with anyone else's. Reconciliation is cross-entity within your own group and never cross-customer. We publish no benchmark, no salary statistic and no aggregate drawn from any customer's registers, and we would have to build something we have deliberately not built in order to do so.
B.3 AI models: where they run and what they learn from
Where models run. All inference runs on GPU instances we operate on cloud infrastructure in Frankfurt: the fine-tuned column classifier that proposes a mapping from a header string and a statistical fingerprint of the column, and the embedding model that proposes identity matches across entities. No third-party inference endpoint is used at any point. No payroll row, no header, no employee name, no salary figure and no entity name is sent to a hosted model API, Microsoft's included. Our cloud infrastructure provider and Microsoft appear on our subprocessor register for compute and storage; no model vendor does, because none is in the path. Nothing is processed outside Frankfurt.
Training. We do not train on your data, and the exception is narrow enough to state exactly. Two corpora accumulate from operator decisions and they are governed differently. The column corpus holds a header string plus a statistical fingerprint of that column, being magnitude, sign, currency formatting, cardinality and null rate, mapped to a field name; it holds no cell values, no names and no salary figures, and it is shared across the service. The identity corpus holds pairs of payroll rows and a decision about whether they are one person; that is employee personal data, so it is partitioned per customer, never pooled across customers, and never used to train, tune or evaluate anything that touches another customer's account. The column classifier is fine-tuned on Azure Machine Learning in Germany West Central, also Frankfurt, and the column corpus is the only corpus used there. The identity corpus is kept in Frankfurt with the rest of the service and is used only inside its own customer's partition. Your entity register, your journals and your exceptions log are used to train nothing at all.
Where a person decides. The model proposes and a person decides, in both places it runs. A column mapping is applied only after one of your operators confirms it, once per file shape. An identity match is applied only when the embedding score and the similarity margin both clear a fixed threshold and an operator confirms it; below the threshold nothing is guessed at, the row stays in the exceptions queue marked unresolved, and the period cannot lock while it sits there. There is no override on that lock for anyone, including us. No automated decision producing legal effects for any individual is made anywhere in this service: Muntin does not calculate pay, does not determine an entitlement, does not move money and does not file with any authority. Every figure that reaches a person's payslip was calculated elsewhere and was cleared here by a named human being.
B.4 Where the data is kept
All storage and all processing sit in Frankfurt. On the cloud infrastructure that runs the service: source files, the entity register, locked period records and the immutable log in object storage, with mapped rows, the exceptions log, both models in service and the identity index. On Microsoft Azure in Germany West Central: the column corpus and classifier training snapshots in Azure Blob Storage. Nothing is held outside Frankfurt.
No inference runs on a third-party endpoint. Column classification and identity embedding are served from cloud GPU instances we operate in Frankfurt, the column classifier is fine-tuned on Azure Machine Learning in Germany West Central, and no payroll row, header, entity name or fragment of one is sent to a hosted model API.
Journals and webhooks are delivered to endpoints you nominate. If your ERP or your webhook consumer sits outside the EU, the delivered payload travels there on your instruction; our copy and all processing stay in Frankfurt.
Support access to a customer account is granted case by case, logged in the same immutable log as everything else, and performed by our staff from within the EU.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
Source files, mapped rows, check results and locked period records: for the life of the subscription and 24 months after it ends, because a posted journal is audited long after the software is switched off. Earlier deletion on written instruction.
The entity register and cost center trees: for the life of the subscription, deleted within 30 days of its end.
The exceptions log, including who cleared what: for the life of the subscription plus 24 months, matching the period records it explains.
Identity match decisions in the per-customer corpus: deleted with the customer account, within 30 days of the end of the subscription.
The shared column corpus: retained indefinitely. It holds header strings and value-shape fingerprints and contains no cell values, no names and no salary figures.
Account and billing records: ten years after the subscription ends, as German commercial and tax record rules require.
Access and delivery logs without payloads: 90 days.
B.6 Requests from people whose data is in the service
Your employees are your data subjects, not ours. If one of them writes to us directly we will not answer on the substance; we will tell them plainly that their employer is the controller, name you, and forward the request to your nominated contact within five working days. On your written instruction we will locate, export, correct or delete a named individual's rows, and a correction after a period has locked produces a new period version rather than a silent edit, so the change is visible rather than hidden. About your own operators we hold work email, name and the exceptions log entries attributable to them; write to [email protected] and we will answer within 30 days.
For everyone
4. Moving data between countries
Muntin Systems GmbH is a company in Germany, inside the EEA. Section B.4 says where the data in the service is kept. If any personal data we control ever has to leave the EEA, for example because a supplier named on our subprocessor list handles it elsewhere, it is protected by the European Commission’s Standard Contractual Clauses or another safeguard the GDPR accepts. You can ask us for a copy.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Muntin Systems GmbH, Katharinenstrasse 17, 04109 Leipzig, Germany