Methodology
Decisions about money get written down, not improvised
Every rule about what a donation figure means, how a receipt number behaves once issued, or which date a report uses is recorded as a numbered Architecture Decision Record before it ships — not settled quietly in a pull request. Below are the ones a finance committee would actually want to read.
- ADR 0002
- Issued export documents never change, ever
- ADR 0006
- Every payment date carries a known precision
- ADR 0007
- Reconciliation matches how the money arrived
- ADR 0010
- A donor sub-ledger, not a general ledger
ADR 0001 — The giving day is the gift-event unit
A busy visit isn't ten loyal donors
DonorCARE treats a donor's behavioral unit as the day they gave, in a fixed Malaysia timezone — not one row per transaction. Someone who buys ten tablets in a single temple visit is one giving day, not ten separate gifts. It sounds small, but it's the difference between an engagement score that rewards genuine loyalty and one that rewards basket size, a common flaw in generic CRM donor scoring.
ADR 0002 — Export documents are immutable
Once a voucher number is issued, its numbers never move
When DonorCARE issues an accounting export document — a voucher number, ledger keys — its bytes and figures never change again, even if the underlying donation is corrected later. A correction becomes a new supplementary document instead of a silent edit. That protects your books from renumbering or double-counting when an accountant reconciles months after the fact.
ADR 0005 — What a ritual registration row is worth
A stored zero doesn't mean nothing was charged
How a pricing-tier row that stores a zero amount reconciles back to what a donor actually paid was signed off by the product owner directly, because it changes reported money — not left to an engineer's judgment call. It's measured against a 97.7% reconciliation rate against the pricing catalogue it draws from. For temples and associations running ritual or tablet-based fundraising, that is the exact number your board asks about.
ADR 0006 — A payment date is an instant with a known precision
The system knows the difference between a minute and a guess
Every payment timestamp passes through one function that distinguishes a gateway-observed instant from an operator-typed calendar day, and records which one it was. A report can never silently claim it knows the exact minute a gift arrived when all it really has is the day someone entered. That is a correctness guarantee behind every statutory receipt DonorCARE issues.
ADR 0007 — A donation reconciles through its settlement channel
Bank reconciliation follows how the money actually moved
A direct bank transfer reconciles against one bank line. A batch of cash or cheques reconciles against one deposit line covering many donations. A gateway payment reconciles against the gateway's own settlement report, not the bank statement. Treating all three the same way is how reconciliation breaks in practice — this rule was checked against real production donation history, not assumed.
ADR 0009 — Dharma checkout rulings
What prints matches what the donor confirmed, by construction
No pre-checked consent boxes on any donor-facing screen — a dark pattern this product does not permit. Before a ritual or memorial donation is paid, the donor must confirm the exact text that will print, with an explicit warning that it cannot be changed afterward. That confirmation text is composed on the server, not approximated on the screen, so there is no gap between what a donor agreed to and what gets printed — directly addressing the top complaint category in ritual and tablet fundraising: a wrong printed name.
ADR 0010 — DonorCARE is a donor sub-ledger
We don't try to be your accounting system
DonorCARE does not own a chart of accounts, a general ledger, or a fiscal-year configuration. It owns three distinct dates — gift date, bank date, entry date — kept separate everywhere, and emits typed records for a separate bookkeeping product to consume. For a treasurer deciding whether DonorCARE replaces or complements existing accounting software, the honest answer is: it complements and feeds it.
Frequently asked questions
Why should we trust how you handle our money and our dates?
Because you don't have to take our word for it. Every rule above is a numbered, dated decision on file, not a paragraph of marketing copy — ADR 0002 says an issued export document never changes; ADR 0006 says every payment date carries a known precision; ADR 0007 says reconciliation follows how the money actually arrived. If one of these rules ever changed, it would show up as a new numbered ADR, not a silent change in behavior.
We already use an accounting system. Does this replace it or feed it?
It feeds it. ADR 0010 states the boundary directly: DonorCARE is a donor sub-ledger, not a general ledger. It doesn't hold a chart of accounts, a trial balance, or a fiscal-year configuration — it owns three distinct dates (gift date, bank date, entry date) and emits typed records for your existing accounting system to consume, via the SQL Accounting export or a CSV/JSON export.
How do you know these rules hold up against real donation data, not just theory?
Because they were checked against it before they shipped. ADR 0007's settlement-channel reconciliation was verified against real production donation history, and ADR 0005's reconciliation rule for stored-zero pricing rows is measured at a 97.7% reconciliation rate against the pricing catalogue it draws from — not asserted, measured.
What happens if a donation is corrected after a receipt or export has already gone out?
The original export document's bytes and figures never change — that's ADR 0002. A correction becomes a new supplementary document instead of a silent edit to the old one, so an accountant reconciling months later never finds a voucher number that quietly moved.
Who signs off on a decision that changes how a donation amount is calculated?
Not an engineer alone. ADR 0005, which decides how a stored-zero pricing row reconciles back to what a donor actually paid, was signed off by the product owner directly because it changes reported money — that's written into the decision record itself, not left as an implicit assumption.
Read the decision, not just the feature
Start on the free plan — every rule above is already running in it, not held back for a higher tier.