ED10 - Sphere Assignment of Business Transactions (from Business Registration, in the Case of Nonprofit Status)

Problem

A nonprofit organization registers a commercial operation - and from that moment, the sphere separation (§§ 51–68 AO) applies. But in practice:

• "Spheres? Never heard of them." - many nonprofit entrepreneurs do not know that they must assign every business transaction to one of four spheres
• Mixing of charitable and commercial activities - workshop income (charitable) and merchandising sales (commercial) end up in the same account, in the same folder, in the same repo
• No sphere label - journal entries have no field indicating the sphere - the auditor has to guess
• Asset commingling as a ground for revocation - § 55 Abs. 1 Nr. 5 AO poses a risk of revocation of nonprofit status in the event of asset commingling - retroactively for up to 15 years
• No automatic check - no one checks whether every business transaction has a sphere - "it'll work out somehow"
• Flat-rate allowances assigned incorrectly - flat-rate allowances for volunteers and instructors (§ 3 Nr. 26/26a EStG) are not assigned to the correct sphere

Trigger A - Business Registration: This obligation arises without employees - it is part of the organization, not of its status as an employer. From the moment a nonprofit organization registers a commercial operation, every business transaction must be assigned to a sphere.

Core Statement

Sphere assignment in the Git repo means:

1. Every business transaction has a sphere field - a required field, not optional (for nonprofit tenants)
2. Four spheres - ideell, vermögensverwaltend, zweckbetrieblich, wirtschaftlich
3. Pre-Commit-Hook checks completeness - no commit without a sphere tag for nonprofit tenants
4. Sphere violation report - automatic warning for a commercial transaction in a charitable context
5. Flat-rate allowances assigned - flat-rate allowances for volunteers/instructors (§ 3 Nr. 26/26a EStG) receive a sphere tag

Compliance by Design: Sphere separation is not achieved through after-the-fact sorting, but through structural required fields and Pre-Commit-Hooks that check every business transaction for sphere assignment.

The Four Spheres

Risk if spheres are not separated: Asset commingling (§ 55 Abs. 1 Nr. 5 AO) is a ground for revocation of nonprofit status. A nonprofit organization that does not separate commercial and charitable transactions risks revocation of its nonprofit status - and thus retroactive taxation of reserves (for up to 15 years).

Sphere Assignment in the JSON Artifact

Every business transaction (journal entry, diary entry, document) includes the sphere field as a required field for nonprofit tenants:

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "<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 entry's DocID. The composite key V7GUID:uuidV7 is used for storage organization and DB queries. The sphere field is mandatory for nonprofit 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 a charitable context) results in a warning, not a rejection - the transaction may be legitimate (e.g., a commercial business operation conducted by the legal entity). However, the warning requires the entrepreneur to deliberately 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, EUR 500) and a workshop (charitable, EUR 200). The Pre-Commit-Hook requires sphere: "wirtschaftlich" and sphere: "ideell", respectively. The Post-Commit-Hook generates a report: commercial EUR 500 (below the threshold), charitable EUR 200. If the threshold is exceeded, the report warns of corporate income tax liability.

Flat-Rate Allowances and Spheres

Flat-rate allowances for volunteers and instructors (§ 3 Nr. 26/26a EStG) must be assigned to the correct sphere:

Important: The flat-rate allowances are tax-exempt - but only if they are assigned to the correct sphere. A volunteer flat-rate allowance in a commercial business operation is not tax-exempt. The sphere field in the diary entry documents the assignment.

Articles of association § 6a: Payment of the flat-rate allowances requires an enabling clause in the articles of association (§ 6a). Until the amendment to the articles has been entered in the commercial register, payment must be deferred - the entitlement arises from the date of the amendment. See ED11 for details.

Risk Leverage

Harness Requirement (Preview)

Derivable from ED10:

The complete requirements list is in Harness-Anforderungen.md.

Sources

• AO (§ 52 - nonprofit status, § 55 Abs. 1 Nr. 5 - asset commingling, § 58 Nr. 1 - asset management, § 64 - commercial business operations, § 64 Abs. 3 - threshold of EUR 45,000, § 65 - special-purpose operations)
• EStG (§ 3 Nr. 26 - instructor flat-rate allowance, § 3 Nr. 26a - volunteer flat-rate allowance)
• E1/agents/ (anonymized) - SSoT concept with sphere separation, pre-commit hooks

Source Topology and CDN Reference Links

Note: This mapping 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 status.