Who this page is for
For Group Finance, corporate tax, and procurement — not for the campaign team.
If you run a network of entities across several countries, paying creators is rarely your problem. You already have treasury, banking relationships, and an AP system. Your problem is proof. When an audit asks where a service was performed, how a fee divides between the performance itself and the usage rights, and which thresholds a single creator has crossed across all your entities within the calendar year — how long does the answer take, and where does it come from?
In most networks, the honest answer is: from calendars, emails, invoices, and the memory of people who have since moved on.
What the status quo actually costs
Two costs that are rarely looked at together.
The administrative burden. For 600 creator collaborations a year, Gigapay's published ROI model puts the manual process at around 139,590 euros across 840 administrative hours — a competitor's own number, but an order of magnitude that matches what the people we talk to describe. Multiply that across your operating units.
The audit exposure. Penalties scale per provider, not per incident:
- DAC7: in Germany, up to 50,000 euros per report; in Sweden, 2,500 to 12,500 SEK per provider; in Spain, around 200 euros per provider
- Künstlersozialabgabe: 4.9 percent on payments to self-employed creatives above 1,000 euros in the calendar year — including creators resident abroad
- § 50a EStG: 15.825 percent withholding tax on payments to foreign creators, with the paying company on the hook if it fails to deduct
Enforcement is not hypothetical. North Rhine-Westphalia has roughly 200 proceedings underway involving an estimated 300 million euros, Hamburg is auditing 140 influencers, and the Deutsche Rentenversicherung runs KSK special audits that reach back several years.
For a network with hundreds of creators per country, that first figure multiplies by the number of providers in scope.
What the Ledger does
CognitivaOS keeps an audit-proof record of the events that create obligations — captured the moment they occur, versioned, and queryable across entities and countries.
Place and period of performance per engagement, not per campaign. The tax rules attach to the individual service; a system that only tracks campaigns cannot answer the question.
Fee allocation across performance, exploitation, and the licensing of rights, as a structured field with a documented basis. This split determines whether exemption limits apply, and it is exactly where a purely contractual label fails to survive an audit.
Threshold tracking per creator, per country, per measure — on a calendar-year or single-transaction basis, depending on the rule. Consolidated across every entity in the network, because thresholds do not respect your internal structure.
Residency indicators independent of how long someone was present, flagging country pairs with no treaty protection.
Permit evidence as a mandatory field in markets where advertising requires a permit — where the due-diligence duty extends to agencies and brands.
Screening of clients and recipients: identity, beneficial owners, business status, register checks, sanctions screening, and scheduled re-review.
DAC7: Cognitiva Systems is registered as a platform operator; the data is collected and sense-checked at onboarding, not scrambled together after the fact.
What we capture
For the record to answer these questions, CognitivaOS collects structured fields from the outset — when the parties are onboarded and when each individual engagement is set up. The overview below shows what gets captured.
Parties — at onboarding
| Field | Purpose |
|---|---|
role | Agency, brand, or creator — determines the applicable screening and reporting logic |
legal_form | Individual, sole trader, or company |
country_of_residence | Country of tax residence |
residence_basis | Where the information comes from: self-declaration, certificate, or verified — never from population-register data |
tax_id | Tax identification number in the country of residence (DAC7) |
vat_id | For Reverse Charge and invoicing |
has_dwelling_in | A dwelling maintained within the meaning of § 8 AO — regardless of days present |
trade_registration | Business registration, GISA number, or Trade Licence, with its scope |
ubo_persons | Beneficial owners from 25 percent |
ubo_register_status | Reconciliation against the register; discrepancies must be documented |
Per engagement
| Field | Purpose |
|---|---|
campaign_id | Link to the campaign as the billing and grouping level |
place_of_performance | Where the service was actually performed |
performance_start / performance_end | Period of performance, the basis for counting days present |
fee_total | Total fee, with currency |
fee_split_performance | Performance portion — § 50a Abs. 1 Nr. 1 EStG |
fee_split_exploitation | Exploitation portion — Nr. 2 |
fee_split_rights | Licensing of rights — Nr. 3, no exemption limit |
fee_split_basis | Basis for the split: contractual, assessed, or default |
travel_reimbursement | Only the amount exceeding actual costs counts as income |
permit_ref / permit_verified_at | Permit evidence where required — gated before publication |
Proof of delivery
| Field | Purpose |
|---|---|
type / channel | Type of post and channel |
contracted_quantity / delivered_quantity | Owed versus actually delivered scope — the point an audit tests |
published_url / published_at | Where it appeared and when |
evidence_ref / evidence_captured_at | An archive copy taken at the time of publication, because posts get deleted |
disclosure_marked | Advertising disclosure present |
usage_scope, usage_rights_from / usage_rights_to, territory | Scope, duration, and territory of the rights granted — the factual basis for the fee split |
accepted_by / accepted_at | Sign-off by the client |
Screening signals (KYB/KYC)
Kept deliberately separate from the tax fields — these are screening signals, not statements of status.
| Field | Purpose |
|---|---|
identity_verified_at | When and how identity was verified |
address_current / address_registered_since | Address screening signal — not proof of residence |
trade_status / trade_status_since | Business status and since when |
company_data_ref | Commercial-register data |
sanctions_screening_at / sanctions_result | Sanctions screening and its result |
review_due_at | Follow-up review |
The tax calculations — per engagement, versioned as of the payment date — and the reporting layers (DAC7, § 50a EStG, US forms, Künstlersozialabgabe) are derived from these fields; they are not collected separately.
Why alongside, not instead of
CognitivaOS does not replace your payment infrastructure. If you work with a Merchant of Record, with your own bank accounts, or with both, that stays exactly as it is. The Ledger reconciles against the channels you already use rather than forcing another one on you.
That is deliberate. A network is not going to rip out its payment infrastructure for the sake of a documentation layer — and a record that only knew about our own payout channel would be useless to you.
Where you do want to run payouts through us, you can: via licensed payment infrastructure in over 100 countries, with a payout product built specifically for India and corridors into the GCC.
The three alternatives
| Manual status quo | In-house build | CognitivaOS | |
|---|---|---|---|
| Lead time | none | 12–24 months to the first reliable analysis | onboarding per unit |
| Ongoing effort | high, grows with campaign volume | maintaining the rule sets yourself | included in the price |
| Rule maintenance | scattered, mostly informal | a permanent in-house specialist | a centrally maintained parameter table with audit annotations |
| Consolidation across entities | manual, error-prone | possible, but laborious | built in |
| Audit readiness | reconstructed after the fact | depends on how you built it | versioned, with the state at payment time retrievable |
The comparison that matters to you is not between providers. It is between carrying on as you are, building it yourself, and buying it in.
Pricing
The Ledger starts at 150 euros per five campaigns, plus processing fees where payouts run through us.
That number is stated plainly on purpose. Set against the administrative cost of a manual process above, it is a rounding error — and set against a single DAC7 report, which in Germany can run to 50,000 euros, more so still.
Networks with multiple entities and consolidated reporting run on a separate model; we work out the terms with you directly.
What is not in place yet
Our ISO 27001 and SOC 2 Type II certifications are in progress. If your review process requires a Type II report at signing, that is a blocker today, and we would rather tell you now than in the third meeting.
Two approaches tend to work here: a contained trial in one unit or one market, or an agreement that ties full rollout to the report landing. We share the security documentation up front either way.
Next step
A session with your tax or finance team where we run the Ledger against one of your real cases — one campaign, several countries, mixed creator residencies. Within an hour you will know whether it answers your questions.
Important notice
Cognitiva Systems Inc. does not provide, and is not authorized to provide, tax or legal advice. The content of this page is for general orientation and is no substitute for advice on your specific situation. CognitivaOS provides documentation and reporting functions; assessing the tax and legal treatment of the recorded facts is for you and your advisers. Any amounts, rates, and deadlines given reflect the position at the time of writing and change constantly.
The ROI model referenced comes from published materials by Gigapay Sweden AB and reproduces its figures, retrieved on 16 August 2026.
Sources
- Gigapay Sweden AB, published ROI model — gigapay.com
- Plattformen-Steuertransparenzgesetz (PStTG); Bundeszentralamt für Steuern, DAC7
- § 50a EStG; Bundeszentralamt für Steuern, guidance on tax withholding
- §§ 1 EStG, 8 and 9 AO
- Künstlersozialversicherungsgesetz; Künstlersozialkasse, 2026 contribution rate
- Bundesministerium der Finanzen, status of double taxation treaties as of 1 January 2026