🎉 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
- Test with real production-like data
- Deploy to staging for team testing
- Code review and approval
- Monitor for errors and gather feedback
- Proceed to Phase 2 (Persistent Consolidation) after validation
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
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
-
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.
-
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_attimestamps are within the period being exported
-
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
-
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
-
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 separateobject_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:
- Clear Identification - Easy to distinguish consolidation documents from business documents
- Flexible Filtering - Can exclude/include from queries as needed
- UI Separation - Default document lists show only business documents
- Proper GoBD Compliance - Sammelbeleg is treated as a legitimate source document (Beleg)
- Document Lifecycle - Benefits from standard document management (archival, retention, permissions)
- Monthly expense reports exist alongside individual receipts
- Summary statements exist alongside transaction details
- Consolidated invoices exist alongside line items
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 formatCONS-{consolidationId}.
Example Scenario
- ✅ 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
PDF Generation Function
Sammelbeleg Document Creation and Storage
Document Relationships & Traceability
Document Storage Without document_relations (Recommended)
Design Decision: Do NOT usedocument_relations for Sammelbeleg ↔ Original Documents.
Rationale:
- Redundant - GL entries already have
sammelbeleg_document_id(source of truth) - Derivable - Can query related documents via GL entries
- Simpler - One less relationship to maintain and keep in sync
- Avoids Confusion - One document can have GL entries in multiple Sammelbelegs (edge case complexity)
- Cleaner Queries - Direct GL-level queries are more accurate
general_ledger.sammelbeleg_document_id
Querying Sammelbeleg and Related Documents
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:| Issue | Without document_relations | With document_relations |
|---|---|---|
| Source of Truth | ✅ Single: general_ledger.sammelbeleg_document_id | ❌ Dual: GL entries + document_relations |
| Edge Case | ✅ Naturally handles documents in multiple Sammelbelegs | ⚠️ Confusing: one document → multiple parent Sammelbelegs |
| Maintenance | ✅ One update: mark GL entries | ❌ Two updates: GL entries + document relations |
| Query Complexity | ✅ Direct GL queries | ⚠️ Need to sync two sources |
| Accuracy | ✅ GL-level precision | ⚠️ Document-level approximation |
| Sync Issues | ✅ Cannot drift | ❌ Can get out of sync |
- Precision - Track at GL entry level, not document level
- Simplicity - One relationship to maintain
- Correctness - Always accurate, cannot drift
- Clarity - UI can show exact GL entries per Sammelbeleg
- 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:-
✅ Core consolidation logic (
@cona/core/general_ledger/consolidate-entries.ts)- Advanced reconciliation handling with union signatures
- Cross-period validation
- Detailed diagnostics
-
✅ Sammelbeleg PDF generation (
apps/webapp/app/lib/utils/generate-sammelbeleg-pdf.tsx)- Using
pdf-lib(Next.js compatible) - Professional German formatting
- Complete audit trail
- Using
-
✅ DATEV export integration
- Consolidation before export
- ZIP generation with Sammelbeleg PDFs
- README documentation
-
✅ UI implementation
- Aggregation toggle enabled (BETA)
- ZIP download support
- Success messages
-
✅ Unit tests
- Consolidation logic tests
- PDF generation tests
- Uses
pdf-libinstead ofpdfkit(better Next.js compatibility) - Enhanced reconciliation logic beyond original spec
- Multiple consolidated entries can share belegfeld1 (optimized PDF generation)
Phase 2: Persistent Consolidation (Period Close) ⏳ PENDING
Status: Not yet started (awaiting Phase 1 validation) Will include:- Database migrations for consolidation tracking
SAMMELBELEGobject_type creation- Document storage implementation
- GL entry updates with consolidation markers
- Consolidation audit logs
Phase 3: Testing & Validation ⏳ IN PROGRESS
Current tasks:- ⏳ Test with real production-like data
- ⏳ Verify 80-90% reduction in export size
- ⏳ Validate PDF content and formatting
- ⏳ Performance testing with large datasets
- ⏳ Deploy to staging
- ⏳ Code review and approval
- ⏳ Monitor logs for errors
- ⏳ User acceptance testing
- ⏳ Consultation with Steuerberater for GoBD compliance confirmation
- 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:- Enable feature flag for production
- Internal rollout first
- Gradual rollout to customers
- Monitor performance and errors
- Gather user feedback
- 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
- 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)
- Index on consolidation key fields (accounts + tax_rate + dimensions, NOT date or amount sign)
- Batch processing for document updates
- Parallel PDF generation (generate multiple Sammelbeleg PDFs concurrently)
- Stream-based ZIP creation for large exports
- Consider PDF generation queue for very large exports (100+ consolidated entries)
Data Integrity
Safety Measures:- Transaction-based consolidation for persistent mode
- Audit trail in
consolidation_logs - Reversibility via
consolidated_from_ids - Reconciliation validation before consolidation
- Sammelbeleg PDFs stored as immutable documents (proper Belege)
- GL entries reference Sammelbeleg documents via
sammelbeleg_document_id - Digital signatures on PDFs for verification
Edge Cases
- Single Entry Groups: Don’t consolidate, export as-is
- Missing Dimensions: Treat as empty object, group separately
- Multiple Currencies: Never consolidate across currencies
- Different Tax Rates: Never consolidate entries with different tax rates (entries are grouped by tax rate)
- Null Tax Rates: Entries with null tax_rate consolidate separately from entries with tax rates
- Algebraic Summation: Positive and negative amounts consolidate together and sum algebraically (e.g., 100 + (-50) = 50)
- Zero Amount Results: If consolidated entries sum to zero, still create a consolidated entry (represents offsetting transactions)
- Deleted Entries: Exclude from consolidation
- Date Range: Store earliest and latest transaction dates in metadata for reference
- Belegdatum: Use the latest transaction date from the consolidated group
- Reconciliation Completeness: Skip consolidation if any reconciliation group is NOT complete within the period
- Partial Reconciliation: Entries with incomplete reconciliation are exported individually, not consolidated
Rollback Strategy
Virtual Consolidation: No rollback needed (non-persistent) Persistent Consolidation:- Keep original entries (mark as consolidated, don’t delete)
- Store mapping in
consolidated_from_ids - Implement
reverseConsolidationfunction if needed
Success Metrics
- Consolidation Ratio: Target 60-90% reduction in entry count
- Note: Ratio depends on reconciliation completeness within period
- Entries with incomplete reconciliation exported individually
- Export Time: < 5 seconds for 10,000 entries
- Data Integrity: 100% reconciliation preservation
- Each consolidated entry is fully reconcilable as a unit
- All original reconciliation groups complete within period
- User Adoption: > 50% of period closes use consolidation
- Error Rate: < 0.1% failed consolidations
- Reconciliation Integrity: 0% partial consolidations (all-or-nothing approach)
Security & Compliance
GoBD Compliance with Sammelbeleg Approach
Key GoBD Principles Maintained:-
Einzelaufzeichnungspflicht (Individual Recording):
- ✅ All individual transactions documented in Sammelbeleg PDF
- ✅ Original dates, amounts, and document references preserved
- ✅ No loss of transaction-level detail
-
Belegprinzip (Document Principle):
- ✅ Sammelbeleg PDF serves as proper source document (Beleg)
- ✅ DATEV Belegfeld 1 references the Sammelbeleg document
- ✅ Follows recognized German accounting practice
-
Nachvollziehbarkeit (Traceability):
- ✅ Clear path from DATEV entry → Sammelbeleg PDF → Original transactions
- ✅ All stored in document management system
- ✅ Digital signatures for verification
-
Unveränderbarkeit (Immutability):
- ✅ PDFs are immutable once generated
- ✅ Original GL entries remain unchanged (marked as consolidated, not deleted)
- ✅ Audit trail in consolidation_logs
-
Aufbewahrung (Retention):
- ✅ Sammelbeleg PDFs archived like any other receipt (10 years)
- ✅ Stored in compliant document management system
Additional Compliance Measures
- Audit Trail: All consolidations logged with actor ID and timestamp
- Data Retention: Original entries and Sammelbeleg PDFs retained for 10+ years
- Access Control: Only period close permissions allow persistent consolidation
- GDPR Compliance: Consolidation doesn’t expose additional PII
- 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:- Consult with a Steuerberater or tax advisor
- Contact DATEV to verify this approach is acceptable
- Review with your Wirtschaftsprüfer (auditor) if applicable
- Document the decision and approvals in your accounting policies
Potential Oversights & Considerations
Fields Currently Included in Consolidation Key ✅
- debit_account_id - ✅ Included
- credit_account_id - ✅ Included
- dimensions (JSON) - ✅ Included (all dimensions)
- currency - ✅ Included
- tax_rate - ✅ Included
- transaction_date - ✅ Explicitly EXCLUDED (by design)
- amount_sign - ✅ Explicitly EXCLUDED (amounts sum algebraically)
- 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_amountis the net amount before taxtax_ratedetermines the tax treatment- With same
tax_rate, thetax_base_amountvalues will naturally sum correctly
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 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_typewith categories: SALES, PURCHASE, INTERNAL - Invoices vs Credit Notes represent opposite business events
- Credit notes typically have negative amounts
- 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_idfor multi-entity organizations - Different legal entities should likely keep separate books
- Consolidating across subsidiaries might violate legal requirements
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_accountshasaccount_type(Debit or Credit enum) - Since we’re consolidating by specific
debit_account_idandcredit_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
- 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
| Field | Currently Handled | Recommendation | Priority | Status |
|---|---|---|---|---|
| tax_base_amount | ❌ Not in key | ✅ No action needed | Low | ✅ Done |
| Amount sign | ✅ EXCLUDED | ✅ Algebraic summation (CORRECT) | HIGH | ✅ Done |
| Document type | ❌ Not in key | ✅ Not needed (amounts sum algebraically) | Low | ✅ Done |
| Subsidiary | ❌ Not in key | ⚠️ Add if using multi-entity | Medium | 🔄 Future |
| Account type | ✅ Implicit | ✅ No action needed | N/A | ✅ Done |
| Entity | ❌ Not in key | ✅ Likely not needed | Low | ✅ Done |
| Organization | ✅ Filtered | ✅ Already handled | N/A | ✅ Done |
✅ Critical Decision Made
Amount Sign Handling - RESOLVED Decision: Allow positive and negative amounts to consolidate together (algebraic summation) ✅ Scenario:export-datev.ts):
- Two separate entries (100S, 50H)
- One consolidated entry (50S)
Open Questions
-
UI for viewing consolidation details?
- Should we add a page to view consolidation history?
- Show consolidation preview before export?
-
Undo consolidation for period close?
- Should persistent consolidation be reversible?
- What’s the business requirement?
-
Consolidation on dimension subsets?
- Allow users to exclude certain dimensions from consolidation?
- Example: Consolidate ignoring “project” dimension?
-
Notification system?
- Send email with consolidation summary after period close?
- Include consolidation statistics in export?
-
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?
-
Belegfeld 1 format? ✅ RESOLVED - USING CUID
- DATEV regex:
^(["][\w$%\-\/]{0,36}["])$ - Allowed characters: alphanumeric, underscore,
$,%,-,/ - Maximum length: 36 characters (excluding quotes)
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_idfield - ✅ Human-readable prefix -
CONS-clearly indicates consolidated entry
- 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
- 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)
- DATEV regex:
-
Amount Sign Handling ✅ RESOLVED - 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
| Benefit | Description |
|---|---|
| GoBD Compliance | Sammelbeleg is a proper “Beleg” (source document), not just metadata |
| Document Management | Full integration with existing document lifecycle (archival, retention, permissions) |
| Traceability | Standard document queries work: “Show me all documents for period X” |
| UI Integration | Can be viewed, downloaded, and managed like any other document |
| Audit Trail | Proper document history, versioning, and actor tracking |
| Retention | Automatic 10+ year retention alongside other accounting documents |
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
- Sammelbeleg (consolidation document) + Original Invoices (business documents) → Different document types, different purposes
Clear Separation via object_type
- ✅ Clear identification of document types
- ✅ Flexible filtering in queries and UI
- ✅ Proper relationships via
document_relations - ✅ GoBD compliance - Sammelbeleg is a legitimate Beleg
- ✅ 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)
- 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
| Aspect | CSV Approach | Sammelbeleg PDF Approach |
|---|---|---|
| Belegprinzip | ❌ CSV not a proper Beleg | ✅ PDF is proper source document |
| Professional Acceptance | ⚠️ Questionable | ✅ Recognized accounting practice |
| Document Storage | ❌ Separate file, not archived | ✅ Stored in document management (10+ years) |
| Audit Workflow | ⚠️ Requires cross-referencing | ✅ Standard workflow (show Beleg) |
| Immutability | ⚠️ CSV can be edited | ✅ PDF immutable, digitally signed |
| Presentation | ❌ Raw data format | ✅ Professional, formatted document |
| GoBD Compliance | ⚠️ Uncertain | ✅ Strong case for compliance |
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
- 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:- ✅ Creates actual source documents (Belege) recognized in German accounting
- ✅ Integrates with existing document retention systems
- ✅ Follows established practice (Sammelbuchungsbeleg)
- ✅ Professional presentation acceptable to tax authorities
- ✅ No ambiguity about which file is the “official” record
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
- Consult with Steuerberater regarding Sammelbeleg approach for GoBD compliance
- Optional: Contact DATEV to verify acceptance of this approach
- Review and approve RFC (pending professional confirmation)
- Create implementation tickets
- Begin Phase 1 development
Change Log
| Date | Change | Author |
|---|---|---|
| 2025-01-04 | ✅ Phase 1 implementation complete - added status update and implementation notes | Development Team |
| 2024-10-29 | Created Phase 1 implementation plan (virtual consolidation MVP) | Development Team |
| 2024-10-24 | Added Sammelbeleg PDF approach for improved GoBD compliance | Development Team |
| 2024-10-23 | Initial RFC creation | Development Team |
Last Updated: 2025-01-04 - Phase 1 (Virtual Consolidation) implementation complete