ED09 - Sphere Classification of Business Transactions (from trade registration, in case of non-profit status)

Problem

A non-profit organization registers a trade - and from that moment the sphere separation (§§ 51-68 AO) applies. But in practice:

• "Spheres? Never heard of them." - many non-profit entrepreneurs do not know that they must assign every business transaction to one of four spheres
• Mixing of ideal and commercial - workshop income (ideal) and merchandising sales (commercial) land on the same account, in the same folder, in the same repo
• No sphere marking - booking entries have no field that indicates the sphere - the auditor must guess
• Asset mixing as a reason for denial - § 55 Abs. 1 Nr. 5 AO threatens denial of non-profit status on asset mixing - up to 15 years retroactively
• No automatic check - no one checks whether every business transaction has a sphere - it will "somehow be right"
• Lump sums wrongly assigned - honorary and exercise leader lump sums (§ 3 Nr. 26/26a EStG) are not assigned to the correct sphere

Trigger A - trade registration: This obligation arises without employees - it is part of the organization, not of being an employer. From the moment a non-profit organization registers a trade, every business transaction must be assigned to a sphere.

Core Statement

Sphere classification in the Git repo means:

1. Every business transaction has a sphere field - mandatory field, not optional (for non-profit tenants)
2. Four spheres - ideell, vermögensverwaltend, zweckbetrieblich, wirtschaftlich
3. Pre-commit hook checks completeness - no commit without sphere tag for non-profit tenants
4. Sphere violation report - automatic warning on commercial transaction in ideal context
5. Lump sums assigned - honorary/exercise leader lump sums (§ 3 Nr. 26/26a EStG) receive sphere tag

Compliance by Design: Sphere separation does not arise through retroactive sorting, but through structural mandatory fields and pre-commit hooks that check every business transaction for sphere assignment.

The four spheres

Risk of missing sphere separation: Asset mixing (§ 55 Abs. 1 Nr. 5 AO) is a reason for denial of non-profit status. A non-profit organization that does not separate commercial and ideal transactions risks the denial of non-profit status - and thus re-taxation of reserves (up to 15 years retroactively).

Sphere classification in the JSON artifact

Every business transaction (booking entry, diary entry, voucher) contains the sphere field as a mandatory field for non-profit tenants:

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "Buchhalter",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "E1",
  "source_sha256": "<SHA-256-...>",
  "tags": ["workshop", "bildungsangebot"]
}

Note: The uuidV7 is the DocID of the entry. The composite key V7GUID:uuidV7 serves the storage organization and DB query. The sphere field is a mandatory field for non-profit tenants - the pre-commit hook checks its presence and validity.

Pre-commit hook checks sphere completeness

Important - warning vs. rejection: A sphere violation (commercial transaction in ideal context) leads to a warning, not a rejection - the transaction can be legitimate (e.g. commercial business operation that belongs to the corporation). But the warning forces the entrepreneur to consciously confirm the classification and document it in the commit.

Sphere report

The post-commit hook generates a sphere report per fiscal year:

Practical example: The entrepreneur (E1) books a merchandising sale (commercial, 500 EUR) and a workshop (ideal, 200 EUR). The pre-commit hook requires sphere: "wirtschaftlich" or sphere: "ideell". The post-commit hook generates a report: commercial 500 EUR (below exemption limit), ideal 200 EUR. On exceeding the exemption limit, the report warns of KSt liability.

Lump sums and spheres

Honorary and exercise leader lump sums (§ 3 Nr. 26/26a EStG) must be assigned to the correct sphere:

Important: The lump sums are tax-free - but only if they are assigned to the correct sphere. An honorary lump sum in the commercial business operation is not tax-free. The sphere field in the diary entry documents the assignment.

Articles § 6a: The payment of the lump sums requires an opening clause in the articles (§ 6a). Until the HR registration of the articles amendment, the payment must be deferred - the claim arises from the date of the articles amendment. See ED10 for details.

Risk-Leverage

Harness requirement (preview)

Derivable from ED09:

The complete requirement list in Harness-Anforderungen.md.

Sources

• AO (§ 52 - non-profit status, § 55 Abs. 1 Nr. 5 - asset mixing, § 58 Nr. 1 - asset management, § 64 - commercial business operation, § 64 Abs. 3 - exemption limit 45,000 EUR, § 65 - purpose operation)
• EStG (§ 3 Nr. 26 - exercise leader lump sum, § 3 Nr. 26a - honorary lump sum)
• AFJD/agents/ (anonymized) - SSoT concept with sphere separation, pre-commit hooks

Source topology and CDN reference links

Note: This assignment of sources, mirror and community hub reflects the current state and may change. Please check the respective canonical source on gitcover.org for the current state.