plaintextaccounting.org: a Pandoc site for the plain text accounting community

A portal that is also the community's front door

The repository is the source for plaintextaccounting.org, described as an information portal and community hub for Plain Text Accounting, and it is maintained by Simon Michael and other members of the community, with the README putting out the call for help. The scope is documentation and examples rather than software. The topics are accounting, beancount, hledger and ledger, and the content strategy is spelled out in the notes on managing examples. The goal is to collect concise, useful example journal entries for common accounting situations, organised into topic pages that are linked from a Cookbook page, with the aim that the examples are reasonably reproducible. The governance of that content is explicitly human and open. The notes list crowd-sourced, human-organised, kept clean, and relatively stable URLs and identifiers so that the pages can be referenced from chat rooms, documentation and software. The list of tools it serves is the plain text accounting family, and the notes even describe a goal of testing the examples automatically against the current release of each tool, marked as something to happen some day. For a reader, the site is the best single place to see how the same accounting situation is written in different tools.

Pandoc, two Lua filters and one template

The build is deliberately small, and knowing it is enough to run the site. The site is markdown pages with double-bracket wiki links, rendered by Pandoc, with the source files in the src folder and the output files and assets in the out folder. The page layout is defined by page.tmpl, which uses normalize, the Skeleton CSS framework and the project's own site.css. The Makefile shows the rest. The default target builds html, which runs Pandoc over every markdown file in src and the quickref subdirectory and writes the matching html into out, and the template file, the two Lua filters and the Makefile are listed as prerequisites so a change to any of them rebuilds the pages. The Pandoc invocation is given in full, with the input format set to markdown-smart-tex_math_dollars+autolink_bare_uris+wikilinks_title_after_pipe, a table of contents flag, the wikilinks.lua and headings.lua Lua filters, and the page template. The two filters are in the repository root, and they are what make the wiki links work and what the headings filter does to the anchor names. The out directory is committed, which means the built site is in the repository as well as being served.

Wiki links, and the Obsidian compatibility bargain

The linking convention is the part of the project that a contributor has to internalise. Alongside ordinary HTML anchors and Markdown links, double-bracketed wiki links are supported in four shapes, a plain link, a link with a section, a link with alternate text, and a link with both, with the pipe for alternate text coming last. The interesting constraint is the interaction with Obsidian. The source files are intended to be somewhat compatible with Obsidian for efficient local editing and viewing, and the README notes that Obsidian expects words in file names and wiki links to be space-separated, while the site requires file names to be hyphen-separated. The site translates spaced wiki links to the hyphenated link targets automatically, so a contributor can write in Obsidian style and the build still resolves. That is a small but real piece of engineering, and it explains why the Makefile carries a comment about keeping the src file names clean, with no apostrophes, because that will break. The lesson for anyone planning to contribute is that the file naming is part of the contract with the build, not a style preference.

Four ways in, from a chat message to a pull request

The contribution section is unusually complete, and it reflects a site that wants to be edited by people who do not want to set up a toolchain. The first option is to drop into the chat room, the #plaintextaccounting room on Matrix.org, and suggest changes, with an older IRC channel on Libera.chat still mentioned. The second is the lowest friction of all, to log in with a GitHub account and use the Edit and New Page buttons at the top right of any page. The third is the classic route, to clone the wiki repository with git and send a pull request or push directly. The fourth is the issue tracker, for discussing issues rather than making changes. The web edit path is spelled out step by step, from clicking the pencil at index.md, through editing the markdown source, checking the Preview tab, to committing with a descriptive message. The README is clear about what happens next, that a commit from someone with commit access is applied immediately, and that otherwise a fork and pull request is created, which the maintainers say they will review soon. A separate note explains how to get commit access, which is to ask in the chat if you are a recurring contributor. There is a wiki repository distinct from the site repository, and the clone command in the README points at the wiki one, so read carefully which you are forking.

Previewing locally, and the case for a two-pane editor

Three preview paths are offered, and the accuracy of each differs. The accurate one is the real build. Running make requires GNU Make and Pandoc 2.5 or newer, and it produces index.html that you open in a browser. For live updating, the README asks for watchexec and livereloadx and then make watch, which serves the site at localhost on port 8100, and the Makefile shows the same thing built from two targets, an auto target that runs watchexec over the make html command and a watch target that starts the regeneration in the background, opens a browser at the live reload port, and runs livereloadx over the out directory with a comment explaining that the reload happens at the end when the CSS and JavaScript are copied. The approximate paths are for quick checks while writing. Obsidian's editing and reading modes work, and so does the VS Code Markdown Preview Enhanced extension, and the README describes the split-pane trick in Obsidian with the pipe key, and the VS Code shortcut of Cmd k Cmd v on a Mac. There is even a note for Emacs users, where S-TAB cycles heading and content visibility and C-x n s and C-x n w narrow to and widen from a section.

How examples are organised, and the file type vocabulary

The example management notes are the editorial policy of the site, and they explain what a good contribution looks like. Each common transaction or situation should have a page, and the pages should show example journal entries, variations and alternative techniques. Examples should be ready to use with one or more of the plain text accounting tools, and while showing multiple tool specific versions is welcome it is not required. Translation and porting tips are welcome too, and the pages should be consolidated with the tool specific sites, the ledger wiki, the hledger cookbook and the beancount command line accounting cookbook, in order to reduce duplicated effort. The notes add that the examples should be reasonably reproducible, and that eventually the examples should be automatically tested against the current release of each tool. There is also a small but practical convention for code blocks. Inside literal blocks you can write a file type after the opening triple backticks, and the suggested types are a generic journal file likely compatible with ledger and hledger, ledger specific, hledger specific, beancount, timeclock and timedot, the delimited values formats csv, ssv and tsv, hledger CSV rules files, and files specific to other applications such as abandon, tackler and nledger. The README notes that these types are not yet well supported by GitHub but might be in the future, and that they also help with automation.

Cloudflare Pages, a GPL licence, and a site with no releases

The publishing arrangement is one line in the README, and it explains why the project can move quickly. The site is rendered by Cloudflare Pages, and changes merged into the master branch should appear at plaintextaccounting.org within a minute or so, with a pointer to the Cloudflare and GitHub status pages if they do not. The Makefile also has a target for building the same html on a Cloudflare Pages server, which installs Pandoc if it is missing by downloading a pinned release, and the repository carries Nix files, a flake lock, a headings.lua and a wikilinks.lua pair, a finance directory, a test directory and a page template. The licence is GPL-3.0, which for a documentation site is the permissive-enough choice and means the prose and the example entries can be reused and adapted under its terms. The repository has no GitHub releases, which is not a problem for a site whose deploys are continuous, and the last push was on 2026-10-08. The result is a piece of infrastructure worth copying, where the editing tools are chosen to match what contributors already use, the build is one make invocation, and the publish step is automatic.

Editorial conclusion

Adopt this repository if you want to contribute examples to the plain text accounting community, or if you want to understand how a wiki-style knowledge site can be built from markdown with Pandoc and Lua filters and still be edited inside Obsidian. It does not fit a team that needs a documentation platform with versioned content, per product namespaces or an editorial workflow, because the site is a single flat set of markdown pages with a shared template. Before you fork it, read the sections on wiki links and on examples, because the two conventions the site imposes, hyphenated file names and a specific literal block file type vocabulary, are the parts that will break your tooling if you ignore them.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. plaintextaccounting/plaintextaccounting on GitHub
4. Project website
5. README