Reconcile SKR03 and SKR04 datasets with DATEV 2026 - #2
Conversation
Verified every account against the official DATEV 2026 chart PDFs (Art.-Nr. 11174/11175) and fixed all findings: - repair truncated/deviating SKR03 labels (0120, 0690, 0790, 1410, 1580, 1610, 2400, 8150, 8960, 8970, 8975) and drop the 8921 qualifier that had leaked onto 8920 - align SKR04 labels 1210, 1320, 3310 with the printed designations - correct balance-sheet side: Anleihen block 0600/0610/0631/0650 and 0690 are liabilities (passiv), 2600 Erträge aus Beteiligungen is ertrag, receivables 1503/1505 are aktiv - correct stale gruppe values (building accounts 0070-0170 under Sachanlagen; 0600-0720 under Verbindlichkeiten) and add untergruppe parent-block context to the "- Restlaufzeit" maturity sub-accounts and duplicate-name building accounts - add three now-exact cross-links (0120<->0710, 2400<->6930, 8150<->4150), total 183 symmetric pairs - fix stale README examples (5817 -> 4964; network range order) - tests: reject labels ending in German function words, enforce designation-implied typ (this check found 1503/1505) - add scripts/verify-datev.mjs: deterministic end-to-end check of both datasets against the DATEV chart PDFs (mupdf dev dependency), with docs/datev-verification.md covering download, usage, and the new-chart-year upgrade workflow; chart PDFs stay gitignored
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1f7c6b3ff3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| { | ||
| "konto": "4946", | ||
| "name": "Fremdleistungen (Nicht-Wareneingang)", | ||
| "name": "Freiwillige Sozialleistungen", |
There was a problem hiding this comment.
After redefining SKR03 4946 from Fremdleistungen to Freiwillige Sozialleistungen, the MCC dataset still uses 4946 for numerous external-service transactions: for example, suggestAccount("7372"), suggestAccount("7361"), and suggestAccount("8911") now return employee benefits as their high-confidence primary account, while several other mappings retain it as a service-related alternative. Audit all MCC references to reassigned account numbers and move these service mappings to an appropriate account such as the newly added 3100.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in af2f068. All 16 references to 4946 (now "Freiwillige Sozialleistungen") were remapped: service MCCs (7339, 7361, 7372, 7399, 8734, 8911, 8999 and the service alternatives) now target 3100 "Fremdleistungen" (cross-linked to SKR04 5900); the 5912 first-aid-supplies alternative moves to 4980 "Sonstiger Betriebsbedarf". The same audit also caught 2650 (now "Erträge aus Beteiligungen") → 2200 "Körperschaftsteuer" and 4980 → 4985 "Werkzeuge und Kleingeräte".
| { | ||
| "konto": "6815", | ||
| "name": "Internetkosten", | ||
| "name": "Bürobedarf", |
There was a problem hiding this comment.
Changing SKR04 6815 from Internetkosten to Bürobedarf leaves existing MCC targets semantically stale: suggestAccount("4816", "SKR04") still returns 6815 for Computer Network/Information Services even though its SKR03 primary 4925 now cross-references 6810. The same shift affects many entries—for example, MCC 5968 still targets 6825, which this commit changes to legal and consulting costs instead of publications—so valid-but-wrong SKR04 account numbers will be returned unless all skr04_primary values are reconciled against the new cross-references.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in af2f068. All skr04_primary values are now derived from the SKR03 primary's cross-reference wherever one exists (56 realigned, e.g. 4816 → 6810 "Internetkosten", 5968 → 6820 "Zeitschriften, Bücher, digitale Medien"). For three targets whose correct SKR04 account was missing from the curated set, the chart-verified accounts 0635 "Geschäftsausstattung", 6320 "Heizung" and 6821 "Fortbildungskosten" were added and cross-linked. A new test enforces skr04_primary === SKR03-link from now on.
| "ust_relevant": false, | ||
| "steuerschluessel": [], |
There was a problem hiding this comment.
For consumers using SKR04.get("6495"), this newly remapped maintenance account reports ust_relevant: false with no tax key, while its exact linked SKR03 account 4806 reports true and [9]. This suppresses input-tax handling for ordinary invoiced hardware/software maintenance; similar stale metadata is visible on other relabeled SKR04 entries such as vehicle repairs 6540, so the enriched fields need to be updated alongside the account designations.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in af2f068. VAT metadata (ust_relevant, steuerschluessel) is now equalized across all 186 cross-linked pairs with SKR03 as the curation anchor — 6495 and 6540 regain ust_relevant with Vorsteuer key 9, 6820 gets the 7 % key 8, 6825 key 9, and stale flags on 1450/6580/4520/4830 were cleared. The cross-reference integrity test now asserts ust_relevant and steuerschluessel equality on every linked pair.
Addresses upstream review findings on scka-de#2: the DATEV 2026 relabeling changed what several account numbers mean, but the MCC mapping and SKR04 VAT metadata still referenced the old meanings. - remap MCC references whose SKR03 account changed meaning: 4946 (now Freiwillige Sozialleistungen) -> 3100 Fremdleistungen for all service MCCs (7339/7361/7372/8734/8911/... and service alternatives), 2650 (now Zinserträge) -> 2200 Körperschaftsteuer, 4980 (now Sonstiger Betriebsbedarf) -> 4985 Werkzeuge und Kleingeräte; the 5912 first-aid-supplies alternative moves to 4980 - realign all 56 skr04_primary values with the SKR03 primary's cross-reference (e.g. 4816 -> 6810 Internetkosten, 5968 -> 6820 Fachliteratur, business services -> 5900 Fremdleistungen) - add chart-verified SKR04 accounts 0635 Geschäftsausstattung, 6320 Heizung, 6821 Fortbildungskosten so Betriebsausstattung-, Heizung- and Fortbildung-MCCs resolve to semantically correct targets (225 accounts, 186 cross-links) - equalize VAT metadata across all linked pairs, SKR03 as anchor (e.g. 6495 Wartungskosten and 6540 Fahrzeug-Reparaturen regain ust_relevant/Vorsteuer key 9; 6820 Fachliteratur 7 % key 8) - tests: skr04_primary must follow the SKR03 cross-reference when one exists; linked pairs must share ust_relevant and steuerschluessel - verify-datev: all 286 SKR03 and 225 SKR04 accounts still chart-clean
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af2f068c88
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| { | ||
| "konto": "0110", | ||
| "name": "Gewerbliche Schutzrechte", | ||
| "name": "Garagen", |
There was a problem hiding this comment.
For consumers relying on the enriched gruppe field, SKR03.get("0110") now describes garages but still classifies them as Immaterielle Vermögensgegenstände, inherited from the former intellectual-property designation. Account 0120 has the same mismatch for buildings under construction, and account 0950 classifies pension provisions as Privatkonten; update these groups alongside the relabeled accounts so downstream balance-sheet categorization is not incorrect.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in 54a078a. Beyond the three named accounts (0110 and 0120 → Sachanlagen with parent-block untergruppe, 0950 → Rückstellungen), a full per-class audit of both charts caught the rest of this class: SKR03 0920 Gesellschafter-Darlehen (typ aktiv → passiv, → Eigenkapital), 0930 → Sonderposten mit Rücklageanteil, 1540 → Forderungen, 7000/7080 inventory accounts (typ aufwand → aktiv, → Bestände); SKR04 Anlagen-im-Bau block 0700–0750 (Finanzanlagen → Sachanlagen), the swapped klasse-2 groups (2100–2300 → Privatkonten, 2900–2978 → Eigenkapital), and 1800/1810 Bank → Liquide Mittel. New designation-implied gruppe tests now guard these invariants alongside the typ rules.
Addresses the follow-up review finding on scka-de#2 (0110, 0120, 0950) and everything else a full per-class audit of both charts surfaced: SKR03 - 0110 Garagen and 0120 Bauten im Bau: Immaterielle Vermögensgegenstände -> Sachanlagen, with the parent-block untergruppe - 0950 Rückstellungen für Pensionen: Privatkonten -> Rückstellungen - 0930 Übrige andere Sonderposten: Privatkonten -> Sonderposten mit Rücklageanteil - 0920 Gesellschafter-Darlehen (Kommanditisten): typ aktiv -> passiv, Privatkonten -> Eigenkapital; 0890/0920 get distinguishing Kapitalanteil untergruppen - 1540 Forderungen aus Gewerbesteuerüberzahlungen: Finanzkonten -> Forderungen - 7000 unfertige Erzeugnisse (Bestand): typ aufwand -> aktiv, Bestandsveränderungen -> Bestände; 7080 likewise Bestände SKR04 - Anlagen-im-Bau block 0700/0710/0740/0750: Finanzanlagen -> Sachanlagen - klasse 2 groups were swapped: 2100-2300 Privat accounts -> Privatkonten, 2900-2978 capital accounts -> Eigenkapital - 1800/1810 Bank and 1460 Geldtransit -> Liquide Mittel; 1300 -> Sonstige Vermögensgegenstände; 6595 -> Betriebliche Aufwendungen (class-level label like its siblings) tests: new designation-implied gruppe rules (Sachanlagen for asset building accounts, Rückstellungen, Liquide Mittel/Finanzkonten, Privatkonten, Eigenkapital) alongside the existing typ rules
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fd8195f570
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| { | ||
| "konto": "0027", | ||
| "name": "Gebäude auf eigenen Grundstücken", | ||
| "name": "EDV-Software", |
There was a problem hiding this comment.
When MCC 1520 is a capital expenditure on a building, mcc_skr_mapping.json still offers account 0027 under exactly that condition. This change redefines 0027 as EDV-Software, so selecting the suggested alternative records construction as an intangible software asset; the building alternative must be moved to an appropriate building account.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in bac1dfa: the 1520 building-capex alternative now targets 0120 "Geschäfts-, Fabrik- und andere Bauten im Bau auf eigenen Grundstücken" (cross-linked to SKR04 0710). The other 0027 reference (5734, perpetual software license > 800€) is intentionally correct — EDV-Software is exactly what that alternative meant.
| "ust_relevant": false, | ||
| "steuerschluessel": [], |
There was a problem hiding this comment.
For every MCC in the new high-confidence car-rental range 3351–3500, the mapping returns 4595 and explicitly reports ust_abzug: true, but this account—and linked SKR04 6595—reports ust_relevant: false with no tax key. Fresh evidence in the final tree is this direct transaction/account contradiction despite the pair now being symmetric, which can suppress input-tax handling for rental invoices.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in bac1dfa: 4595 and linked 6595 are now ust_relevant with Vorsteuer key 9, consistent with ust_abzug on every car-rental MCC. A cross-axis audit of all ust_abzug=true mappings found the remaining primaries with ust_relevant=false are balance-sheet asset accounts (0320, 0400, 0410, 0420 — the dataset convention keeps asset accounts VAT-neutral) and 4910 Porto (letter postage is VAT-exempt under § 4 Nr. 11b UStG while courier invoices still carry deductible VAT), so those are conventions rather than relabeling artifacts.
| @@ -2193,79 +2325,89 @@ | |||
| }, | |||
| { | |||
| "konto": "4800", | |||
| "name": "Reparaturen und Instandhaltungen", | |||
| "name": "Reparaturen und Instandhaltungen von technischen Anlagen und Maschinen", | |||
There was a problem hiding this comment.
After narrowing 4800 to repairs of technical plants and machinery, unchanged MCC mappings still use it for Electronics Repair (7622), Small Appliance Repair (7629), and Furniture Repair (7641). In particular, furniture repairs now resolve to machinery maintenance even though the newly relabeled 4805 covers other assets and business equipment, so these mappings need to be reconciled with the narrower account meaning.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in bac1dfa: 7622, 7629, 7641, and 7699 now resolve to 4805 (repairs of other assets and business equipment), with the new chart-verified SKR04 counterpart 6470 as skr04_primary — DATEV spells the designation "Instandhaltungen" (SKR03) vs "Instandhaltung" (SKR04), so the pair cannot be exact-label cross-linked. The 5065 alternative stays on 4800 since electrical parts for repairs fit the machinery account.
| { | ||
| "konto": "6620", | ||
| "name": "Geschenke abziehbar ohne §37b EStG", | ||
| "name": "Geschenke nicht abzugsfähig ohne § 37b EStG", |
There was a problem hiding this comment.
For consumers of SKR04.get("6620"), the account is now explicitly named Geschenke nicht abzugsfähig, but its retained note says it is deductible up to €50 per recipient; 6625 likewise retains the old “over €50” note after becoming Geschenke ausschließlich betrieblich genutzt. These notes describe the accounts' former meanings and can lead callers to apply the opposite deductibility treatment.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in bac1dfa: 6620's note is now "Über 50€ pro Empfänger/Jahr" (synced from linked SKR03 4635), 6610 gained the matching deductible-up-to-50€ note from 4630, and 6625 is rewritten to state that exclusively-business-use gifts fall outside the 50€ limit. The cross-reference test now asserts note parity on every linked pair, and an audit of all other notes on renamed accounts found no further stale entries.
| @@ -2447,15 +2565,15 @@ | |||
| }, | |||
| { | |||
| "konto": "4969", | |||
| "name": "Aufwendungen für Software (Nutzungsrechte)", | |||
| "name": "Aufwendungen für Abraum- und Abfallbeseitigung", | |||
There was a problem hiding this comment.
Although structured software mappings were moved to 4964, the notes returned for MCC 5815 and 5816 still tell users to use 4969 for software or game-studio research. This change makes 4969 an account for excavation and waste-removal expenses, so callers following those notes can still book software purchases to the newly unrelated account.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in bac1dfa: the 5815 and 5816 notes now reference 4964. An audit of every account number embedded in MCC notes and alternative conditions found the remaining references (4676/4666 travel split, 4650 Bewirtungsbeleg, 4210 coworking rent) all still match their current designations.
Fourth review round on scka-de#2 surfaced the last enrichment axes that were still curated against pre-relabeling account meanings. This commit fixes the findings and closes the class with a full cross-axis audit (account notes, MCC notes, alternative conditions, ust_abzug vs ust_relevant): - 4595/6595 Fremdfahrzeugkosten are VAT-relevant (Vorsteuer key 9); every car-rental MCC reports ust_abzug true against them - MCC 1520 building-capex alternative moves from 0027 (now EDV-Software) to 0120 Bauten im Bau auf eigenen Grundstücken - equipment/furniture repair MCCs 7622/7629/7641/7699 move from 4800 (now machinery-only) to 4805; new chart-verified SKR04 counterpart 6470 added (no exact-label link possible: DATEV spells "Instandhaltungen"/"Instandhaltung" differently across charts) - gift-account notes follow the corrected designations: 6610/6620 synced from their linked SKR03 accounts, 6625 rewritten (exclusively business-use gifts are outside the 50-euro limit) - MCC 5815/5816 notes no longer steer software bookings to 4969 - linked pairs must now share notes (test), alongside name, typ, ust_relevant, and steuerschluessel Audited clean: all other account notes on renamed accounts, all account-number references embedded in MCC notes/conditions, and all ust_abzug=true mappings (remaining primaries with ust_relevant=false are balance-sheet asset accounts and the VAT-exempt Porto account, which are conventions, not relabeling artifacts).
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bac1dfa6f2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "konto": "8600", | ||
| "name": "Erlösschmälerungen", | ||
| "konto": "8591", | ||
| "name": "Sachbezüge 7 % USt (Waren)", |
There was a problem hiding this comment.
When consumers use SKR03.get("8591") to determine tax treatment, the newly relabeled Sachbezüge 7 % USt account still returns tax key 1, which every other revenue account in this dataset uses for 19% USt; all comparable 7% revenue accounts use key 2. This can cause benefits in kind booked through this account to be taxed at the wrong rate.
Useful? React with 👍 / 👎.
| ], | ||
| "skr04": "5425" | ||
| }, | ||
| { | ||
| "konto": "3435", | ||
| "name": "Innergemeinschaftlicher Erwerb 19% Vorsteuer und 19% Umsatzsteuer", | ||
| "name": "Innergemeinschaftlicher Erwerb ohne Vorsteuer und 19 % Umsatzsteuer", |
There was a problem hiding this comment.
For an intra-community acquisition without input-tax deduction, SKR03.get("3435") now explicitly says ohne Vorsteuer but retains tax key 9, which the dataset assigns to 19% Vorsteuer accounts such as 3400 and 3425. The linked SKR04 account 5435 carries the same metadata, so consumers applying these keys can incorrectly claim input tax on transactions where the account designation excludes it.
Useful? React with 👍 / 👎.
| { | ||
| "name": "german-accounting", | ||
| "version": "0.1.0", | ||
| "version": "0.2.0", |
There was a problem hiding this comment.
The manifest is bumped to 0.2.0, but both the top-level version and packages[""] .version in package-lock.json remain 0.1.0. This leaves the committed dependency-tree metadata inconsistent with the package being released and causes tooling that reads the lockfile to report the old package version; regenerate or update the lockfile as part of the version bump.
Useful? React with 👍 / 👎.
1 participant
Summary
skr04_primaryfrom the SKR03 primary's cross-reference, and correct the reversed car-rental/lodging network rangesust_relevant,steuerschluessel) across all cross-linked pairsscripts/verify-datev.mjs: a deterministic end-to-end check that parses the official DATEV chart PDFs and verifies every dataset account number, reservation status, and designation against them (seedocs/datev-verification.md); the copyrighted PDFs themselves stay out of the repositoryWhy
The previous data combined obsolete identifiers, labels assigned to the wrong account numbers, PDF line-wrap artifacts, and enriched metadata inherited from unrelated accounts. Some MCC suggestions therefore resolved to accounts whose DATEV 2026 meaning had changed (e.g. SKR03 4969 now "Abraum- und Abfallbeseitigung"; software licenses belong on 4964/6837). SKR04 also was not validated against a JSON Schema in CI.
Validation
npm run verify:datevagainst the official DATEV 2026 chart PDFs: all 286 SKR03 and all 226 SKR04 accounts verified — every account number exists as a named (non-reserved) account and every designation matches the chart verbatim (0 findings)R-marked in the 2026 chartsnpm test(68 tests, incl. designation-implied-typ, truncated-label, skr04_primary-follows-link, and VAT-parity checks)npm run typecheck,npm run buildAlso tracked on our fork as JUVOJustin#1, which stays open for our own integration; happy to adjust anything for upstream.