Skip to main content

🎉 Implementation Status Update (2025-01-04)

Phase 1 (Virtual Consolidation) is COMPLETE and ready for testing! Implemented:
  • Core consolidation logic with advanced reconciliation handling
  • Sammelbeleg PDF generation using pdf-lib
  • DATEV export integration with ZIP download
  • UI toggle enabled with BETA label
  • Comprehensive unit tests
Next Steps:
  1. Test with real production-like data
  2. Deploy to staging for team testing
  3. Code review and approval
  4. Monitor for errors and gather feedback
  5. Proceed to Phase 2 (Persistent Consolidation) after validation
📖 See Phase 1 Implementation Details: gl-entry-consolidation-phase1-virtual.mdx

Executive Summary

Implement GL entry consolidation to reduce the number of entries in DATEV exports by aggregating entries with matching accounts and dimensions. This RFC outlines a hybrid approach that uses virtual consolidation for test exports and persistent consolidation for period closure exports. Key Goals:
  • Reduce DATEV export line count by consolidating similar entries
  • Maintain reconciliation integrity (Belegfeld 1)
  • Generate Sammelbeleg (Collective Receipt) PDF for each consolidated entry
  • Store Sammelbeleg as proper source document (Beleg) for GoBD compliance
  • Provide full audit trail through formal supporting documentation
Critical Design Decision: Consolidation happens ONLY by accounts + dimensions, NOT by date. This means entries from different dates (e.g., Jan 10, Jan 15, Jan 20) that share the same debit account, credit account, and dimensions will be consolidated into a single entry. The date range is preserved in metadata, and the latest date is used as the Belegdatum in the DATEV export. Reconciliation Constraint: Only entries where ALL reconciliation groups are complete/closed within the exported period can be consolidated. This ensures each consolidated entry is fully reconcilable. A new Belegfeld 1 is assigned to the consolidated entry (format: CONS-{cuid}, e.g., CONS-clh5z1234567890abcdef), which references a Sammelbeleg PDF containing all individual transaction details. Rationale: Accounting periods typically span multiple days, weeks, or months. Consolidating across dates provides maximum reduction in export size (potentially 80-90% reduction vs 40-60% with date grouping) while maintaining accounting accuracy. This is standard practice in accounting consolidation. Example Impact:

Problem Statement

Current Situation

DATEV exports contain one line per general ledger entry, which can result in:
  • Large CSV files with thousands of entries
  • Difficult to review and verify exports
  • Redundant data when multiple transactions share the same characteristics
  • DATEV import processing overhead

User Requirements

  1. Consolidate entries that match on:
    • Debit account
    • Credit account
    • All GL dimensions (including custom dimensions)
    • Tax rate - Entries must have the same tax rate (or both null)
      • Rationale: Different tax rates represent different tax treatment and must be kept separate
    • NOT by transaction date - Entries from different dates CAN be consolidated together
      • Rationale: Accounting periods often span multiple days/weeks/months. Consolidating across dates reduces export size significantly while maintaining account accuracy. The date range is preserved in metadata for reference.
    • NOT by amount sign - Positive and negative amounts CAN be consolidated together
      • Rationale: Amounts are summed algebraically (e.g., +100, +150, -50, +200 = 400). In DATEV export, the consolidated amount is always exported as an absolute value with the Soll/Haben indicator (S or H) determined by the final sign. Since we always use “S” for the consolidated entries in this implementation (debit posting), consolidating across signs maximizes reduction while maintaining accounting accuracy.
  2. Reconciliation Completeness Constraint - Only consolidate entries where ALL reconciliation groups are complete/closed within the exported period
    • Rationale: Ensures each consolidated entry represents a complete reconcilable unit
    • Critical: Prevents partial reconciliation exports (e.g., consolidating entries where some reconcile in Period 1 and others in Period 2)
    • Implementation: Check that all reconciliation_groups.reconciled_at timestamps are within the period being exported
  3. New Belegfeld 1 Assignment - Generate a NEW reconciliation ID (Belegfeld 1) for each consolidated entry
    • Rationale: Indicates to DATEV that this consolidated entry is reconcilable as a complete unit
    • Format: CONS-{cuid} (e.g., CONS-clh5z1234567890abcdef)
    • Benefit: Simplifies DATEV export - one line per consolidated entry with single Belegfeld 1
  4. Provide transparency and GoBD compliance:
    • Generate Sammelbeleg (Collective Receipt) PDF for each consolidated entry
    • Store PDF as proper source document (Beleg) in document management system
    • PDF contains full detail of all consolidated transactions
    • Store consolidation metadata in document custom properties
  5. Hybrid approach:
    • Virtual (non-persistent) consolidation for “Test File” exports (PDF generated but not stored)
    • Persistent consolidation for “Close Period and Export” operations (PDF stored as document)

Proposed Solution

Architecture Overview

Database Schema Changes

General Ledger Table Extensions

Consolidation Logs Table (Audit Trail)

Object Type for Sammelbeleg Documents

Design Decision: Dedicated Object Type

Why use a separate object_type for Sammelbeleg documents? Sammelbeleg documents are stored in the documents table alongside regular business documents (invoices, receipts, etc.), which might initially seem like “duplication.” However, using a dedicated object_type_id = "SAMMELBELEG" provides clear separation: Benefits:
  1. Clear Identification - Easy to distinguish consolidation documents from business documents
  2. Flexible Filtering - Can exclude/include from queries as needed
  3. UI Separation - Default document lists show only business documents
  4. Proper GoBD Compliance - Sammelbeleg is treated as a legitimate source document (Beleg)
  5. Document Lifecycle - Benefits from standard document management (archival, retention, permissions)
Example Queries:
This is NOT duplication - it’s proper document categorization. Similar to how:
  • Monthly expense reports exist alongside individual receipts
  • Summary statements exist alongside transaction details
  • Consolidated invoices exist alongside line items
The Sammelbeleg is a derived summary document that serves a different purpose than the original business documents.

Consolidation Logic

Grouping Key Algorithm

Entries are grouped for consolidation using a composite key (excluding transaction date):

Consolidation Process

Reconciliation Handling

Key Constraint: Only consolidate entries where ALL reconciliation groups are complete within the exported period. Key Implementation: Each consolidated entry gets a NEW Belegfeld 1 (reconciliation ID) in format CONS-{consolidationId}.

Example Scenario

Counter-Examples (Would NOT be consolidated): Example 1: Incomplete Reconciliation
Example 2: Different Tax Rates
Example 3: Positive and Negative Amounts (Algebraic Summation)
Reconciliation Completeness Flow: DATEV Export Strategy: Single Line with New Belegfeld 1 (Chosen Approach)
Benefits:
  • ✅ Simpler export (one line per consolidated entry)
  • ✅ Clear indication that entry is reconcilable as a unit
  • ✅ DATEV recognizes the entry as complete and reconciled
  • ✅ Original reconciliation groups preserved in metadata for audit

Core Function: consolidateGLEntries

Sammelbeleg PDF Generation

What is a Sammelbeleg?

A Sammelbeleg (collective receipt/document) is a recognized German accounting practice where multiple similar transactions are documented on a single supporting document. This serves as the “Beleg” (source document) for the consolidated general ledger entry, maintaining the GoBD principle of Belegprinzip (document principle). Key Benefits:
  • ✅ Creates a proper source document (Beleg) for consolidated entries
  • ✅ Maintains GoBD compliance through formal supporting documentation
  • ✅ Provides complete audit trail in professional format
  • ✅ Integrates with existing document management system
  • ✅ Can be archived for 10+ years like any other receipt
  • ✅ Printable for physical audits if needed

PDF Structure

Note: Transaction dates vary from 2024-01-10 to 2024-01-25, demonstrating that entries from different dates are consolidated together in one Sammelbeleg.

PDF Generation Function

Sammelbeleg Document Creation and Storage

Document Relationships & Traceability

Design Decision: Do NOT use document_relations for Sammelbeleg ↔ Original Documents. Rationale:
  1. Redundant - GL entries already have sammelbeleg_document_id (source of truth)
  2. Derivable - Can query related documents via GL entries
  3. Simpler - One less relationship to maintain and keep in sync
  4. Avoids Confusion - One document can have GL entries in multiple Sammelbelegs (edge case complexity)
  5. Cleaner Queries - Direct GL-level queries are more accurate
The Single Source of Truth: general_ledger.sammelbeleg_document_id
Query via GL entries (single source of truth):

Document Hierarchy Visualization (Simplified)

Why Not Use document_relations?

Question: Should we create parent-child relationships between Sammelbeleg and original documents? Answer: No, for these reasons: Edge Case Example:
Benefits of GL-Only Approach:
  1. Precision - Track at GL entry level, not document level
  2. Simplicity - One relationship to maintain
  3. Correctness - Always accurate, cannot drift
  4. Clarity - UI can show exact GL entries per Sammelbeleg
  5. Storage - GL entry details already in Sammelbeleg’s custom_properties

DATEV Export Integration

Updated Export Flow

ZIP Download Implementation

UI Changes

Enable Aggregation Toggle

Update Download Handler

Implementation Plan

Phase 1: Virtual Consolidation (Non-Persistent) ✅ COMPLETE

Status: ✅ Fully implemented and ready for testing What was delivered:
  1. ✅ Core consolidation logic (@cona/core/general_ledger/consolidate-entries.ts)
    • Advanced reconciliation handling with union signatures
    • Cross-period validation
    • Detailed diagnostics
  2. ✅ Sammelbeleg PDF generation (apps/webapp/app/lib/utils/generate-sammelbeleg-pdf.tsx)
    • Using pdf-lib (Next.js compatible)
    • Professional German formatting
    • Complete audit trail
  3. ✅ DATEV export integration
    • Consolidation before export
    • ZIP generation with Sammelbeleg PDFs
    • README documentation
  4. ✅ UI implementation
    • Aggregation toggle enabled (BETA)
    • ZIP download support
    • Success messages
  5. ✅ Unit tests
    • Consolidation logic tests
    • PDF generation tests
Dependencies installed:
Key Differences from Plan:
  • Uses pdf-lib instead of pdfkit (better Next.js compatibility)
  • Enhanced reconciliation logic beyond original spec
  • Multiple consolidated entries can share belegfeld1 (optimized PDF generation)
See: Phase 1 Implementation Details

Phase 2: Persistent Consolidation (Period Close) ⏳ PENDING

Status: Not yet started (awaiting Phase 1 validation) Will include:
  1. Database migrations for consolidation tracking
  2. SAMMELBELEG object_type creation
  3. Document storage implementation
  4. GL entry updates with consolidation markers
  5. Consolidation audit logs
Dependencies:

Phase 3: Testing & Validation ⏳ IN PROGRESS

Current tasks:
  1. ⏳ Test with real production-like data
  2. ⏳ Verify 80-90% reduction in export size
  3. ⏳ Validate PDF content and formatting
  4. ⏳ Performance testing with large datasets
  5. ⏳ Deploy to staging
  6. ⏳ Code review and approval
  7. ⏳ Monitor logs for errors
  8. ⏳ User acceptance testing
  9. Consultation with Steuerberater for GoBD compliance confirmation
Expected deliverables:
  • Test results with real data
  • Performance benchmarks
  • User feedback
  • Professional GoBD compliance confirmation
  • Decision to proceed to Phase 2

Phase 4: Production Rollout ⏳ FUTURE

After successful testing:
  1. Enable feature flag for production
  2. Internal rollout first
  3. Gradual rollout to customers
  4. Monitor performance and errors
  5. Gather user feedback
  6. Iterate based on feedback

Technical Considerations

Performance

Estimated Performance:
  • Consolidation for 10,000 entries: ~2-3 seconds
  • DATEV CSV generation: ~1 second
  • Sammelbeleg PDF generation: ~200-500ms per PDF (depends on entry count)
  • ZIP creation with multiple PDFs: ~1-2 seconds
Example Scenario:
  • 10,000 original entries → 50 consolidated entries
  • 50 Sammelbeleg PDFs × 300ms = ~15 seconds for PDF generation
  • Total export time: ~20 seconds (acceptable for period close)
Optimization strategies:
  1. Index on consolidation key fields (accounts + tax_rate + dimensions, NOT date or amount sign)
  2. Batch processing for document updates
  3. Parallel PDF generation (generate multiple Sammelbeleg PDFs concurrently)
  4. Stream-based ZIP creation for large exports
  5. Consider PDF generation queue for very large exports (100+ consolidated entries)

Data Integrity

Safety Measures:
  1. Transaction-based consolidation for persistent mode
  2. Audit trail in consolidation_logs
  3. Reversibility via consolidated_from_ids
  4. Reconciliation validation before consolidation
  5. Sammelbeleg PDFs stored as immutable documents (proper Belege)
  6. GL entries reference Sammelbeleg documents via sammelbeleg_document_id
  7. Digital signatures on PDFs for verification

Edge Cases

  1. Single Entry Groups: Don’t consolidate, export as-is
  2. Missing Dimensions: Treat as empty object, group separately
  3. Multiple Currencies: Never consolidate across currencies
  4. Different Tax Rates: Never consolidate entries with different tax rates (entries are grouped by tax rate)
  5. Null Tax Rates: Entries with null tax_rate consolidate separately from entries with tax rates
  6. Algebraic Summation: Positive and negative amounts consolidate together and sum algebraically (e.g., 100 + (-50) = 50)
  7. Zero Amount Results: If consolidated entries sum to zero, still create a consolidated entry (represents offsetting transactions)
  8. Deleted Entries: Exclude from consolidation
  9. Date Range: Store earliest and latest transaction dates in metadata for reference
  10. Belegdatum: Use the latest transaction date from the consolidated group
  11. Reconciliation Completeness: Skip consolidation if any reconciliation group is NOT complete within the period
  12. Partial Reconciliation: Entries with incomplete reconciliation are exported individually, not consolidated

Rollback Strategy

Virtual Consolidation: No rollback needed (non-persistent) Persistent Consolidation:
  1. Keep original entries (mark as consolidated, don’t delete)
  2. Store mapping in consolidated_from_ids
  3. Implement reverseConsolidation function if needed

Success Metrics

  1. Consolidation Ratio: Target 60-90% reduction in entry count
    • Note: Ratio depends on reconciliation completeness within period
    • Entries with incomplete reconciliation exported individually
  2. Export Time: < 5 seconds for 10,000 entries
  3. Data Integrity: 100% reconciliation preservation
    • Each consolidated entry is fully reconcilable as a unit
    • All original reconciliation groups complete within period
  4. User Adoption: > 50% of period closes use consolidation
  5. Error Rate: < 0.1% failed consolidations
  6. Reconciliation Integrity: 0% partial consolidations (all-or-nothing approach)

Security & Compliance

GoBD Compliance with Sammelbeleg Approach

Key GoBD Principles Maintained:
  1. Einzelaufzeichnungspflicht (Individual Recording):
    • ✅ All individual transactions documented in Sammelbeleg PDF
    • ✅ Original dates, amounts, and document references preserved
    • ✅ No loss of transaction-level detail
  2. Belegprinzip (Document Principle):
    • ✅ Sammelbeleg PDF serves as proper source document (Beleg)
    • ✅ DATEV Belegfeld 1 references the Sammelbeleg document
    • ✅ Follows recognized German accounting practice
  3. Nachvollziehbarkeit (Traceability):
    • ✅ Clear path from DATEV entry → Sammelbeleg PDF → Original transactions
    • ✅ All stored in document management system
    • ✅ Digital signatures for verification
  4. Unveränderbarkeit (Immutability):
    • ✅ PDFs are immutable once generated
    • ✅ Original GL entries remain unchanged (marked as consolidated, not deleted)
    • ✅ Audit trail in consolidation_logs
  5. Aufbewahrung (Retention):
    • ✅ Sammelbeleg PDFs archived like any other receipt (10 years)
    • ✅ Stored in compliant document management system

Additional Compliance Measures

  1. Audit Trail: All consolidations logged with actor ID and timestamp
  2. Data Retention: Original entries and Sammelbeleg PDFs retained for 10+ years
  3. Access Control: Only period close permissions allow persistent consolidation
  4. GDPR Compliance: Consolidation doesn’t expose additional PII
  5. Professional Verification: Recommendation to consult Steuerberater before production use

Important Note

⚠️ While the Sammelbeleg approach significantly strengthens GoBD compliance compared to simple consolidation, it is strongly recommended to:
  1. Consult with a Steuerberater or tax advisor
  2. Contact DATEV to verify this approach is acceptable
  3. Review with your Wirtschaftsprüfer (auditor) if applicable
  4. Document the decision and approvals in your accounting policies

Potential Oversights & Considerations

Fields Currently Included in Consolidation Key ✅

  1. debit_account_id - ✅ Included
  2. credit_account_id - ✅ Included
  3. dimensions (JSON) - ✅ Included (all dimensions)
  4. currency - ✅ Included
  5. tax_rate - ✅ Included
  6. transaction_date - ✅ Explicitly EXCLUDED (by design)
  7. amount_sign - ✅ Explicitly EXCLUDED (amounts sum algebraically)
  8. Reconciliation completeness - ✅ Validated (all must be complete in period)

Fields NOT Currently Considered (Analysis)

1. tax_base_amount ⚠️ CONSIDER

Current: Not in consolidation key Question: Should entries with same tax_rate but different tax_base_amount be kept separate? Analysis:
  • tax_base_amount is the net amount before tax
  • tax_rate determines the tax treatment
  • With same tax_rate, the tax_base_amount values will naturally sum correctly
Recommendation:No action needed - If tax rates match, base amounts will aggregate correctly. Example:

2. Amount Sign (Positive vs Negative) ✅ EXCLUDED (CORRECT)

Current: ✅ Explicitly EXCLUDED from consolidation key Decision: Allow positive and negative amounts to consolidate together (algebraic summation) Analysis:
  • In DATEV export, amounts are ALWAYS exported as absolute values using Math.abs(amount)
  • The sign is indicated separately by "Soll-/Haben-Kennzeichen" field (S or H)
  • Negative amounts don’t create different transactions - they switch the debit/credit indicator
  • Consolidating entries with mixed signs results in correct algebraic summation (e.g., 100 + (-50) = 50)
DATEV Export Behavior:
Why This is Correct:
  • ✅ DATEV doesn’t distinguish amounts by sign - only by Soll/Haben
  • ✅ Algebraic summation (100 + (-50) = 50) correctly represents the net accounting effect
  • ✅ Consolidated result will have correct Soll/Haben indicator based on final sign
  • ✅ Simplifies consolidation logic
  • ✅ No need to track amount sign in the consolidation key

3. Document object_type / TYPE_CATEGORY ✅ NOT NEEDED

Current: Not in consolidation key Question: Should invoices consolidate with credit notes? Analysis:
  • Documents have object_type with categories: SALES, PURCHASE, INTERNAL
  • Invoices vs Credit Notes represent opposite business events
  • Credit notes typically have negative amounts
Recommendation:NOT NEEDED Since amount signs consolidate together algebraically, invoices and credit notes will naturally consolidate if they share the same accounts and dimensions. This is correct behavior because:
  • The net accounting effect is what matters (100 invoice - 50 credit note = 50 net revenue)
  • DATEV export handles the sign via Soll/Haben indicator
  • Document-level detail is preserved in the consolidation report CSV

4. Subsidiary ⚠️ CONSIDER FOR MULTI-ENTITY

Current: Not in consolidation key Question: Should entries from different subsidiaries consolidate together? Analysis:
  • Documents have subsidiary_id for multi-entity organizations
  • Different legal entities should likely keep separate books
  • Consolidating across subsidiaries might violate legal requirements
Recommendation: ⚠️ ADD IF USING SUBSIDIARIES Implementation:
However: GL entries don’t have direct subsidiary_id - it’s on the document level. This might already be captured in dimensions.

5. Account Type (CHART_OF_ACCOUNT_TYPE: Debit vs Credit) ✅ COVERED

Current: Implicitly covered by account IDs Question: N/A - Already handled Analysis:
  • Each chart_of_accounts has account_type (Debit or Credit enum)
  • Since we’re consolidating by specific debit_account_id and credit_account_id, the account types are implicit
  • No additional consideration needed

6. Entity (Customer/Supplier) ⚠️ CONSIDER

Current: Not in consolidation key Question: Should entries for different customers consolidate together? Analysis:
  • Documents have entity_id (customer/supplier)
  • From an accounting perspective, revenue from Customer A vs Customer B might be the same account
  • From an audit perspective, keeping customers separate might be valuable
Recommendation: ⚠️ LIKELY NOT NEEDED
  • For financial reporting, customer identity doesn’t matter (account balance is what matters)
  • Customer tracking is handled at document level, not GL entry level
  • If needed, entity could be added to dimensions

7. Organization (org_id) ✅ COVERED

Current: Filtering by org_id Question: N/A - Already handled Analysis:
  • All queries filter by org_id
  • Entries from different organizations will never consolidate
  • ✅ Already implemented correctly

Summary of Recommendations

✅ Critical Decision Made

Amount Sign Handling - RESOLVED Decision: Allow positive and negative amounts to consolidate together (algebraic summation) ✅ Scenario:
Why This Works: In DATEV export (see export-datev.ts):
Since DATEV always uses absolute amounts with a separate Soll/Haben indicator, there’s no accounting difference between:
  • Two separate entries (100S, 50H)
  • One consolidated entry (50S)
Both represent the same net accounting effect. Implementation: Amount sign is explicitly EXCLUDED from the consolidation key.

Open Questions

  1. UI for viewing consolidation details?
    • Should we add a page to view consolidation history?
    • Show consolidation preview before export?
  2. Undo consolidation for period close?
    • Should persistent consolidation be reversible?
    • What’s the business requirement?
  3. Consolidation on dimension subsets?
    • Allow users to exclude certain dimensions from consolidation?
    • Example: Consolidate ignoring “project” dimension?
  4. Notification system?
    • Send email with consolidation summary after period close?
    • Include consolidation statistics in export?
  5. Partial reconciliation handling?
    • Should we provide a report of entries that couldn’t be consolidated due to incomplete reconciliation?
    • Alert users when consolidation ratio is lower than expected?
  6. Belegfeld 1 format?RESOLVED - USING CUID
    • DATEV regex: ^(["][\w$%\-\/]{0,36}["])$
    • Allowed characters: alphanumeric, underscore, $, %, -, /
    • Maximum length: 36 characters (excluding quotes)
    Selected Format: CONS-
    Why CUID?
    • Collision-resistant - Better uniqueness than shortened UUID
    • Sortable - CUIDs are lexicographically sortable by creation time
    • No truncation - Uses full CUID (25 chars), not a shortened version
    • Well within limit - 30 characters total (6 chars under limit)
    • Simple to implement - No slicing or hashing needed
    • No database changes - CUID stored directly in consolidation_id field
    • Human-readable prefix - CONS- clearly indicates consolidated entry
    CUID Format:
    • Length: 25 characters
    • Characters: lowercase letters and digits (a-z, 0-9)
    • Pattern: starts with letter, followed by timestamp-based + random segments
    • Collision resistance: ~3.6 × 10^47 possible combinations
    Alternatives Considered (Not Chosen):
    • Shortened UUID (8 chars): Lower uniqueness, requires truncation
    • Database Sequence: Requires schema changes, not globally unique
    • Timestamp-based: Collision risk within same millisecond
    • Hash-based: More complex, deterministic (not guaranteed unique)
  7. Amount Sign HandlingRESOLVED - EXCLUDED
    • Positive and negative amounts consolidate together (algebraic summation)
    • DATEV export uses absolute amounts with Soll/Haben indicator
    • Correct accounting behavior: 100 + (-50) = 50

Document Storage Strategy

Storing Sammelbeleg as documents Record

Decision: Store Sammelbeleg PDFs as proper document records in the documents table with a dedicated object_type_id = "SAMMELBELEG". Rationale: This approach treats Sammelbeleg documents as first-class accounting documents rather than mere metadata or attachments. This is NOT duplication—it’s proper document categorization.

Key Benefits

Not Duplication—Document Hierarchy

Think of it like:
  • Bank Statement (summary) + Individual Transactions (details) → Both are valid documents
  • Expense Report (summary) + Individual Receipts (details) → Both archived separately
  • Consolidated Invoice (summary) + Line Items (details) → Both part of audit trail
Similarly:
  • Sammelbeleg (consolidation document) + Original Invoices (business documents) → Different document types, different purposes

Clear Separation via object_type

This design provides:
  1. Clear identification of document types
  2. Flexible filtering in queries and UI
  3. Proper relationships via document_relations
  4. GoBD compliance - Sammelbeleg is a legitimate Beleg
  5. No confusion - users see business docs by default, consolidation docs on demand

Why Sammelbeleg PDF Instead of CSV?

The Evolution

Original Approach (Rejected):
  • Export separate CSV with consolidation details
  • Two-file dependency (DATEV CSV + consolidation CSV)
  • CSV not recognized as proper “Beleg” (source document)
Sammelbeleg Approach (Chosen):
  • Generate formal PDF documents (Sammelbeleg = Collective Receipt)
  • Store PDFs as proper source documents in document management system
  • DATEV Belegfeld 1 references the Sammelbeleg document ID

Key Advantages

GoBD Compliance Comparison

CSV Approach Concerns:
  • CSV is not traditionally recognized as a “Beleg” (source document)
  • Tax authorities may question split-file approach
  • DATEV import only sees consolidated entries, not details
  • Requires explanation of cross-referencing system
Sammelbeleg Approach Benefits:
  • Aligns with traditional German accounting concept of “Sammelbuchungsbeleg”
  • PDFs stored like any other receipt/invoice
  • Clear audit trail: DATEV → Document System → PDF with all details
  • Professional format acceptable in tax audits
  • Follows established accounting practice

Recommendation

The Sammelbeleg PDF approach is significantly stronger for GoBD compliance because:
  1. ✅ Creates actual source documents (Belege) recognized in German accounting
  2. ✅ Integrates with existing document retention systems
  3. ✅ Follows established practice (Sammelbuchungsbeleg)
  4. ✅ Professional presentation acceptable to tax authorities
  5. ✅ No ambiguity about which file is the “official” record
However, even with Sammelbeleg approach, professional confirmation is still recommended before production use.

References

  • DATEV Format Specification v13
  • GoBD Compliance Requirements (BMF-Schreiben vom 28.11.2019)
  • Existing reconciliation system (reconciliation_groups)
  • Current DATEV export implementation
  • German accounting best practices for Sammelbuchungsbeleg

Approval

Status: Draft - Awaiting Review Reviewers:
  • Backend Lead
  • Product Owner
  • Finance/Accounting Team
  • QA Lead
Next Steps:
  1. Consult with Steuerberater regarding Sammelbeleg approach for GoBD compliance
  2. Optional: Contact DATEV to verify acceptance of this approach
  3. Review and approve RFC (pending professional confirmation)
  4. Create implementation tickets
  5. Begin Phase 1 development

Change Log


Last Updated: 2025-01-04 - Phase 1 (Virtual Consolidation) implementation complete