BeeCount: A Flutter Bookkeeping App With Five Sync Backends and an MCP Server

The Problem BeeCount Targets: Bookkeeping Apps That Own Your Ledger

Most expense trackers put your transaction history on a vendor's servers and give you no way to audit what happens to it. BeeCount is aimed at people who find that unacceptable but still want a mobile app rather than a spreadsheet. The README frames the contrast directly, listing "data stored with a third party, unauditable" and "privacy may be analysed and exploited" against BeeCount's own claims of open source code, offline-first operation, and five selectable sync schemes. The target user is someone with a NAS, a VPS, or a Docker-capable machine who is comfortable configuring a backend. The project is explicitly Chinese-first: the README is in Chinese with a separate English file, the interface ships in Simplified Chinese, Traditional Chinese and English, and the AI capture features are built around GLM-4 and screenshots from Alipay, WeChat and UnionPay. If your receipts come from those apps, the OCR path is aimed at you. If they do not, the AI features are less relevant and you are left with a competent but conventional ledger.

Local Storage in Drift, Sync as a Swappable Layer

The architecture is Flutter on top of Riverpod for state and Drift over SQLite for local persistence. Transactions land in the local database first; sync is a separate concern with five documented backends. BeeCount Cloud is the project's own server, distributed as a Docker image that bundles both the sync server and a web management front end, so opening the server address in a browser gives you a web client. It pushes changes over WebSocket, which is how the README claims devices see an edit within seconds. iCloud is the zero-configuration option but only for iOS. Supabase is positioned for users who want cross-platform sync without running a NAS. WebDAV covers Synology, UGREEN and Nextcloud. S3 covers Cloudflare R2, AWS S3 and MinIO. The data model supports multiple ledgers each with its own currency, multiple accounts where transfers update both sides, two-level category hierarchies, monthly and per-category budgets, recurring entries on daily through yearly schedules, and colour-coded tags. CSV import is documented for Alipay and WeChat statements, and YAML export handles configuration. The BeeCount Cloud layer adds multi-user isolation, shared ledgers with Owner and Editor roles, per-transaction attribution of who recorded and who edited an entry, and AES-256 encrypted backups fanned out to R2, S3, WebDAV or B2. The README notes those backups are standard AES zip archives, so recovery does not depend on the app.

Building From Source and the Commands the README Gives

The development section is short but concrete. You need Flutter 3.27 or newer. The sequence is flutter pub get, then dart run build_runner build --delete-conflicting-outputs to generate the Drift and Riverpod code, then flutter run --flavor dev. Release builds use flutter build apk --flavor prod --release. Note that the flavour flag is not optional in the documented commands, so a plain flutter run will not match the README's instructions. If you only want to use the app, the README points at the App Store listing, Google Play, a TestFlight link and APK builds attached to GitHub releases; the current release line is 3.8.0. Self-hosting is a separate repository, TNT-Likely/BeeCount-Cloud, which the README describes as a one-command Docker deployment with the full Compose tutorial and backup documentation living there rather than in the app repository. That split matters: if you clone the app repo expecting deployment manifests, you will not find them. The MCP integration is documented at count.beejz.com/docs/mcp and is described as requiring BeeCount Cloud, so the LLM-driven bookkeeping path is not available to someone syncing through WebDAV or iCloud alone.

The Licence Badge and the Licence File Do Not Agree

The repository metadata reports the licence as NOASSERTION, while the README badge reads "Business Source License". Those two signals point in different directions, and the README does not reproduce the licence terms. A Business Source License is source-available rather than open source in the OSI sense: it typically permits non-production use and converts to a stated open licence after a change date, with the specific restrictions defined in the licence text itself. None of that detail appears in the material available here. The README's marketing copy repeatedly calls the project "completely open source" and says the code is auditable, which is true in the narrow sense that you can read it, but the phrase carries a different meaning than it does for an MIT or Apache-2.0 project. If you are evaluating BeeCount for anything beyond personal use, read the actual licence file in the repository before you build on it. This is not legal advice and the terms are not summarised here because they are not present in the supplied material.

AI Capture Is Tied to a Cloud Model, Not to the Device

The AI features are the part most likely to disappoint someone who chose BeeCount for privacy. The README describes a dual-engine OCR setup: a local TFLite model plus a GLM cloud engine, with the cloud engine handling recognition of Alipay, WeChat and UnionPay screenshots. Voice entry is described as using GLM to interpret spoken phrasing, and the AI assistant is built on Zhipu's GLM-4. So while the ledger itself is local-first, the capture path sends text or images to a third-party model provider. The README does not state what is transmitted, whether it is opt-in per capture, or whether the local TFLite engine alone can handle a given screenshot. That is the sharpest gap in the documentation. The screenshot automation also depends on platform-specific hooks: an Android accessibility service that listens for screen content, and an iOS Shortcuts back-tap trigger. Both are the kind of integration that breaks when the host platform changes its rules, and neither is described with a fallback. If you want fully offline capture, the README does not confirm that path exists end to end.

BeeCount Cloud Versus Just Using Supabase

The most useful comparison is between BeeCount Cloud and the Supabase option, because both give you cross-platform sync and both are self-managed. Supabase is the lower-effort choice: the README describes it as having a generous free tier and simple configuration, and it is a hosted Postgres platform, so you create a project and paste credentials. BeeCount Cloud is the higher-effort choice, requiring Docker and a machine to run it on, but it is the only backend that provides the web management interface, multi-user registration on one server, shared ledgers with role assignment, and WebSocket push for near-real-time updates across devices. It is also the only backend the MCP integration works with. So the decision is not about sync reliability but about which features you need. If you want a web client and shared household books, Supabase will not give you either. If you want the minimum operational surface, running Docker to get a web UI you may not use is the wrong trade. iCloud, WebDAV and S3 sit outside this comparison entirely: they are storage targets, not application servers, and they do not provide the collaborative features.

Maintenance Burden and What Upgrades Actually Cost

The release cadence visible in the material is roughly one to two weeks between tagged versions, with 3.7.2, 3.7.3 and 3.8.0 spanning mid-August to early September 2026. That is a fast-moving project, which cuts both ways: fixes arrive quickly, and so does churn. If you self-host BeeCount Cloud, you own the upgrade path for the Docker image and for the encrypted backup archives, and the README does not describe a migration procedure for schema changes between server versions. The backup design is the mitigating factor here, since AES zip archives are recoverable with standard tools rather than a proprietary restore flow. On the client side, the Flutter and Dart toolchain requirement of 3.27 or newer means anyone building from source is tracking a framework that also moves quickly, and the build_runner code generation step has to be rerun whenever the Drift schema or Riverpod providers change. For a user installing from the App Store or Play Store, none of this applies; the maintenance cost falls on the project. For a self-hoster, the ongoing cost is keeping a container current and verifying that the backup fan-out to R2, S3, WebDAV or B2 is still writing archives you can open.

Who Should Take This On

BeeCount fits a specific profile: someone tracking personal or household expenses across more than one device, who already runs a NAS or a VPS, who wants the ledger under their own control, and who is comfortable with Docker or with pointing an app at a WebDAV or S3 bucket. The shared-ledger feature with per-transaction attribution makes it unusually well suited to a household where two people record into the same book and want to know who entered what. It is a poor fit for someone who wants a managed service with no operational responsibilities, since every sync option except iCloud requires you to configure something. It is also a poor fit for anyone who needs a permissive licence, given the NOASSERTION metadata and the Business Source License badge. And it is a poor fit for anyone who wants the AI capture to stay entirely on-device, because the documented OCR and voice paths route through GLM. The single thing to verify before adopting is the licence file, followed by whether the MCP and shared-ledger features you may be attracted to actually require BeeCount Cloud, which the README indicates they do.

Editorial conclusion

Adopt BeeCount if you want a Flutter bookkeeping app where the sync target is your own infrastructure and you are willing to run a Docker container or point the app at WebDAV or S3. Do not adopt it if you need a permissive OSI licence, or if you expect a stable public API surface for third-party integrations, since the README does not describe one. Before committing, read the licence file in the repository rather than the badge, confirm which sync backend you will actually operate, and check that your Flutter toolchain is at 3.27 or above if you intend to build from source.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TNT-Likely/BeeCount on GitHub