Zum Hauptinhalt springen

Hosted Ledgers lösen jetzt Managed Price Includes auf

Veröffentlicht Zuletzt aktualisiert 10 Minuten LesezeitMike ThriftMike Thrift
Hosted Ledgers lösen jetzt Managed Price Includes auf
Auf dieser Seite

Seien wir ehrlich: Deine Bestände sind in deinem Ledger bereits perfekt erfasst. Es sind die Preise, die dich in einem endlosen Kreislauf des ständigen Neutippens gefangen halten.

Diese Asymmetrie ist die älteste und frustrierendste Plackerei im Plain-Text-Accounting. Du schreibst einen Kauf einmal auf, und er steht für immer fest: 120 NWRB {41.80 USD, 2024-03-12} schreibt dauerhaft eine Menge, einen Cost und ein Datum fest. Nichts, was danach passiert, ändert diese Fakten. Ein Preis dagegen ist das genaue Gegenteil – er stimmt für genau einen Tag und wird dann still und leise falsch. Schlimmer noch: Er wird auf eine Weise falsch, die keine Bilanzprüfung jemals bemerken wird, denn ein Ledger mit veralteten Preisen balanciert trotzdem perfekt.

Historisch bestand der Beancount-Weg darin, Preise mit einem Skript abzurufen und die Ausgabe zu committen. Das funktioniert, und viele haben es automatisiert. Aber am Ende des Tages ist es immer noch ein Skript, das du betreuen musst, ein Cron-Job, den du pflegst, und eine Datei, die du ständig mergst.

Damit ist jetzt Schluss. Für Ledgers, die auf beancount.io gehostet werden, übernimmt unsere Engine diese Auflösung jetzt nativ. Dieser Beitrag erklärt genau, was gerade ausgeliefert wurde, was wir bewusst nicht angetastet haben und – ebenso wichtig – was wir noch nicht gebaut haben.


Was ausgeliefert wurde​

Ein gehostetes beancount.io-Ledger kann jetzt eine include-Directive tragen, die auf eine URL statt auf einen lokalen Dateinamen zeigt:

; main.bean, in a hosted beancount.io ledger.
;
; This page is German, so the quote currency is EUR. On another language of
; this site, use the currency in the list under the fence.
 
option "title" "Taxable brokerage"
option "operating_currency" "EUR"
 
; Only the hosted engine resolves the URL form, and upstream `include` takes a
; file glob — so the line is shown commented out here and this file still
; loads if you copy it to your own machine. Uncomment it in a hosted ledger.
; include "https://beancount.io/prices/AAPL-EUR"

Achtung: Du musst dich anmelden, bevor du diese URL aufrufst. Anonyme Anfragen werden auf die Login-Seite umgeleitet. Diese Seite ist auf Deutsch, deshalb quotet das Beispiel Euro – die Währung, in der die Leser hier am häufigsten ihre Bücher führen. Sobald du authentifiziert bist, öffne https://beancount.io/prices/AAPL-EUR und vergewissere dich, dass du standardmäßige price-Directives siehst. Füge dann diese Zeile deinem gehosteten Ledger hinzu.

Wenn du in einer anderen Sprache liest, verwende stattdessen die in dieser Sprache übliche Währung – und nur, wenn der Katalog sie als Quote listet:

Der Katalog unter https://beancount.io/prices/ liegt hinter demselben Login. AAPL-USD selbst ist ein direkter Databento-Quote, keine Kreuzung. Andere Tier-1-Aktien funktionieren genauso – tausche den Ticker aus und behalte die Quote-Währung für deine Sprache. ACME-USD liefert einen 404.

Upstreams Beancount-include erwartet technisch gesehen einen Dateinamen, ein URL-Include ist also striktes Verhalten der Hosted-Engine. Sie gibt nie vor, reines Beancount zu sein. Hier ist genau, was unsere Engine unter der Haube tut:

  • Sie materialisiert den Feed als schreibgeschützte virtuelle Datei. Die URL wird über den eigenen Include-Resolution-Pfad der Engine aufgelöst – landet also genau dort, wo eine lokale Datei gelandet wäre –, sodass jede Directive einen echten Source-Standort behält. Deine ursprünglichen Bytes werden nie umgeschrieben. Die Datei, die du geschrieben hast, bleibt die Datei, die du geschrieben hast.
  • Strikte Payload-Validierung. Der abgerufene Body wird als price-only validiert. Wir erlauben strikt price-Directives, Kommentare und vier spezifische Metadaten-Schlüssel (price-source, price-kind, observed-at und provisional). Alles andere lehnt den gesamten Body ab. Es gibt keine teilweise Übernahme, das heißt, ein bösartiger Feed kann niemals eine Transaktion in deine Bücher schmuggeln.
  • Intelligentes Caching. Feeds werden als unveränderliche Revision mit einem beweglichen Pointer zwischengespeichert. Aktualisierungszyklen werden von Timestamps statt von Cache-Ablauf gesteuert, sodass ein Upstream-Ausfall deine letzte gute Revision nicht auslöscht.
  • Auditierbare Aktualität. Die Aktualität wird dynamisch berechnet, wenn das Ledger gelesen wird (aktuell, veraltet oder nicht verfügbar), zusammen mit der vom Feed gemeldeten Beobachtungszeit. Ein Preis, den du nicht datieren kannst, ist ein Preis, den du nicht auditieren kannst.
  • Strikt schreibgeschützt. Managed Einträge können nicht bearbeitet oder gelöscht werden (ein Versuch wirft einen Fehler, der die Quelle benennt). Außerdem zählen sie nicht gegen deine Directive-Limits – wir lassen nicht zu, dass Feeds das Budget deines Ledgers auffressen.

Nichts davon ändert, was eine Price-Directive in Beancount grundsätzlich bedeutet. Die einzige Aufgabe der Engine ist es, korrekte, datierte und zuordenbare Preise vor den Loader zu legen.


Dein eigener Preis gewinnt immer​

Das ist der Knackpunkt für jeden, der sein Ledger ernst nimmt, also lassen wir es glasklar sein:

Für dasselbe Datum und dasselbe Commodity-Paar (einschließlich seines Kehrwerts) gewinnt ein Preis, den du selbst geschrieben hast, immer gegenüber dem Managed Feed.

Nicht „meistens" und nicht „nur, wenn du dein Include zuletzt einfügst". Diese Verdrängungsentscheidung passiert bevor die Price Map gebaut wird, das heißt, sie ist völlig unabhängig davon, wo das include in deiner Datei steht. Setz es an den Anfang, ans Ende oder verteile es über drei Dateien – dein handgeschriebener Preis gewinnt immer.

Die Kehrwert-Regel wird leicht übersehen, ist aber entscheidend. Ein Feed von AAPL-USD ist ein Preis von AAPL in USD. Wenn du einen Preis andersherum handgeschrieben hast – USD in AAPL, gleiches Datum –, schlägt dein Eintrag den Feed trotzdem. Dasselbe gilt für die Quote, die du eingebunden hast, ob CNY oder JPY.

Warum diese Regel? Weil ein Preis in deiner eigenen Datei eine bewusste Entscheidung ist. Es mag der exakte Schlusskurs sein, den dein Broker auf einem Auszug gedruckt hat, den du abstimmst, ein zeitgleicher Quote für ein illiquides Asset oder ein spezifischer Wert, den dein Steuerberater verlangt hat. Ein Feed kennt deinen Kontext nicht. Ein System, das still und leise einen von einem Menschen verfassten Wert überschreibt, hört auf, ein Ledger zu sein, und wird zu einer Meinung. Der Feed ist dazu da, Lücken zu füllen; er korrigiert dich nicht.


Preise verändern die Bewertung, und sonst nichts​

Diese nächste Zusicherung ist struktureller Natur und keine Policy-Entscheidung, und sie lässt sich am besten mit echten Zahlen zeigen. Wirf einen Blick auf unser Krypto-Beispiel-Ledger mit datierten Lots, Staking, DeFi-Positionen und Airdrops:

Ziehen wir einen bestimmten Eintrag heraus. Ein Governance-Token-Airdrop trifft ein und wird als Einkommen zum Fair Market Value am Tag seines Eingangs erfasst:

2024-03-20 * "Uniswap" "Receive UNI governance token airdrop"
  Assets:Crypto:Wallet:MetaMask:UNI       50.00 UNI {12.50 USD, 2024-03-20}
  Income:Crypto:Airdrops                -625.00 USD
 

Diese 625,00 $ Einkommen und die am Lot hängende Basis von 12,50 $ pro Einheit sind jetzt unveränderliche Fakten über den 2024-03-20. Jede Price-Directive im Ledger – ob managed, handgeschrieben oder gänzlich fehlend – lässt beide unangetastet.

Preise ändern den Marktwert; sie verändern niemals Mengen, Cost Basis, Cashflows, Gebühren oder realisierte Gewinne. Genau deshalb ist ein Price Feed ein sicheres Werkzeug, auf das man sich stützen kann: Das absolut Schlimmste, was ein schlechter Preis anrichten kann, ist, vorübergehend falsch darzustellen, was eine Position heute wert ist. Er kann niemals die harten Zahlen korrumpieren, die du in deine Steuererklärung einträgst.


Wo ein falsches Preismodell dich tatsächlich in die Irre führt​

Das Aktien- und ETF-Beispiel-Ledger illustriert die schärfere Version genau dieses Punktes:

Es enthält einen 4-für-1-Aktiensplit, auf die richtige Weise erfasst – als Mengenänderung, die die Gesamtbasis erhält, ohne irgendein Einkommenskonto zu berühren:

2025-07-15 * "Broker" "NWRB 4-for-1 share split — quantity change, not income"
  Assets:Brokerage:NWRB                   -120 NWRB {41.80 USD, 2024-03-12}
  Assets:Brokerage:NWRB                    480 NWRB {10.45 USD, 2024-03-12}
 

Beide Seiten ergeben 5.016,00 $. Der Marktwert bleibt über den Split hinweg unverändert (7.440,00 $ in beiden Fällen), und das Anschaffungsdatum in den geschweiften Klammern überlebt – was dafür sorgt, dass ein Verkauf dieser Aktien im Jahr 2026 als langfristig eingestuft wird.

Die häufige Falle besteht darin, einen Split stattdessen als Preisereignis zu erfassen und sich stark auf eine „split-bereinigte" Preisreihe zu stützen, damit die Mathematik aufgeht. Das funktioniert nur, solange jeder Preis, den du jemals betrachtest, auf exakt dieselbe Weise bereinigt wurde. In dem Moment, in dem eine unbereinigte Zahl in dein Ledger gelangt – eine alte Abrechnung, ein Screenshot oder ein Drittanbieter-Feed, der historische Werte nicht neu darstellt –, wird die Position plötzlich mit dem Vierfachen ihres tatsächlichen Werts bewertet. Schlimmer noch: Die Aktienanzahl im Ledger stimmt nicht mehr mit dem Auszug deines Brokers überein, was bedeutet, dass deine Saldenprüfungen zum Jahresende still und leise fehlschlagen.

Das ist das eigentliche Argument dafür, sich auf einen Price Feed mit deklarierter Quelle, deklarierter Art und sichtbarer Beobachtungszeit zu stützen. Es geht nicht nur um Bequemlichkeit; es geht darum, genau zu wissen, welche mathematische Konvention deine importierten Zahlen verwenden.

(Ein kurzer Hinweis zu den Embeds: Der Hosted-Ledger-Viewer rendert Kontosalden zu Anschaffungskosten und bietet derzeit keine Bewertungssteuerung auf der Seite. Die obigen Ledgers sollen die zugrunde liegende Mechanik zeigen – die Lots, den Split, die Verkäufe. Beide sind öffentlich, und du kannst sie klonen und lokal ausführen.)


Was noch nicht da ist​

Wir glauben, ein Changelog ist schlimmer als nutzlos, wenn es zu viel verspricht. Hier ist also die ungeschminkte Wahrheit darüber, was wir noch nicht gebaut haben, ohne angehängte Zeitpläne:

  • Authentifizierung ist Pflicht. Anonyme Anfragen an https://beancount.io/prices/<ALIAS> bringen dich auf eine Login-Seite.
  • Keine lokale CLI-Unterstützung. Die lokale bea-CLI liest Dateien von der Festplatte, ein URL-Include wird lokal also als nicht übereinstimmender Datei-Glob fehlschlagen. Loader-Unterstützung für die CLI steht auf unserer Roadmap.
  • Keine API-Oberfläche. Wir haben derzeit kein REST-, GraphQL- oder MCP-Feld für Managed Prices.
  • Kein UI-Dashboard. Es gibt noch keinen „Connect-a-Feed"-Bildschirm und kein Aktualitäts-Label in der UI. (Die von unserer Engine berechneten Aktualitätsdaten haben derzeit keinen Ort, an dem sie angezeigt werden.)
  • Keine Snapshots, Exporte oder manuellen Refresh-Endpunkte.

Was wir heute ausgeliefert haben, ist strikt die Engine-Ebene: Include-Auflösung, Validierung, Revisions-Caching, Precedence-Regeln und Aktualitätsberechnung. Es ist die fundamentale Infrastruktur, auf der alles andere stehen muss – genau deshalb haben wir sie zuerst gebaut.


Wo du als Nächstes schauen solltest​

Beide oben eingebetteten Ledgers sind Teil unserer Beispielgalerie – sechs vollständig ausgearbeitete Muster, die du klonen und lokal ausführen kannst. (Beide werden absichtlich mit statischen, eingecheckten Preisdateien ausgeliefert, sodass ein Klon, der zwei Jahre von jetzt erstellt wird, exakt denselben Report erzeugt wie heute.) Alles andere, was wir ausliefern, landet direkt in unserem Changelog.

Wenn du vollkommen zufrieden damit bist, Preise mit deinem eigenen Fetcher aktuell zu halten, bleib dabei. Er bleibt die beste Antwort für ein strikt lokales Ledger. Beancounts eigene Dokumentation zum Abrufen von Preisen und das gepflegte beanprice-Tool sind die besten Ausgangspunkte.

Lass den langweiligen Teil langweilig bleiben​

Preise sind es wert, automatisiert zu werden, gerade weil sie der einzige Teil eines Plain-Text-Ledgers sind, der mit der Zeit verrottet. Beancount.io ist darauf ausgelegt, dir Plain-Text-Accounting zu geben, das dein bleibt – auditierbar, versionskontrolliert und niemals hinter deinem Rücken umgeschrieben. Das war der Mindeststandard, den ein Managed Feed erfüllen musste, bevor wir bereit waren, ihn auszuliefern.

Starte kostenlos und führe deine Bücher in Dateien, die du tatsächlich lesen kannst.

Quelle: https://beancount.io/de/blog/2026/09/17/managed-price-includes-hosted-ledgers

Veröffentlicht: 17. September 2026

Zuletzt aktualisiert: 19. September 2026