Feature
Record a donation, have it approved if your trust works that way, issue it under your own numbering series, and void it if it was wrong. What happened to each receipt stays on its own timeline.
A receipt in Jinseva Receipts is a record of one donation — the donor, the amount, the date, the donation head, the donation type and how the money arrived — that moves through four states: draft, pending approval, issued and voided.
Issuing is the moment that matters. It allocates the next number in your series, closes the receipt against further editing, and freezes onto it the receipt design, the organisation’s details and the signatory it was issued under.
Which actions are available depends on the state a receipt is in and the permissions the person holds. Both are checked on the server, not just hidden in the interface.
A recorded donation that has not been issued. It can be edited or deleted, it holds no receipt number, and it appears in no report of issued receipts.
A draft that has been submitted. Somebody holding the approval capability can approve it or reject it with a reason; a rejected receipt goes back to draft so it can be corrected and submitted again.
The receipt has taken the next number in your series and is final. It cannot be edited and cannot be deleted. This is the point at which the design, the organisation details and the signature are frozen onto it.
An issued receipt withdrawn with a reason. It keeps its number — so the series has no unexplained gap — and reports count it as voided rather than as money received. Voiding is final; a correction is a new receipt.
Receipt numbers are how a trust’s book reconciles, so the series is configuration rather than something the software decides.
Three checks a trust can set to match how it actually works, on the receipt settings screen.
A receipt is evidence, and evidence that changes when the surrounding records change is not evidence.
No. Once a receipt is issued it cannot be edited or deleted.
A mistake is corrected by voiding the receipt, with a reason, and issuing a new one. The voided receipt keeps its number and is reported as voided, so the numbering series stays continuous and the correction is visible rather than silent.
No — approval is a setting, and it is off by default.
With it turned on, a draft must be submitted and approved before anyone can issue it, and the application refuses to issue a receipt that has not been approved. With it off, somebody holding the issue capability can issue a draft directly.
From a series your organisation configures: a prefix, a starting number, how many digits to pad to, and whether the count restarts each financial year.
Numbers are allocated at the moment of issue, not when the draft is created, so a draft that is never issued does not consume one. Two people issuing at the same time cannot receive the same number.
That is your organisation’s decision, recorded as a setting. Back-dating can be left unrestricted or limited to a number of days.
Future-dated receipts are refused by default and can be allowed. A duplicate warning — the same donor and amount on the same day — is on by default and warns rather than blocks.
Every step, on the receipt’s own timeline: created, updated, submitted, approved or rejected, issued, voided, and everything that happened to it afterwards.
That includes the document being generated, and each time it was emailed, downloaded, printed, delivered or bounced — one history rather than two, because an auditor asks about the receipt, not about the transmission.
A new organisation is created with donation heads, donation types, payment methods and two published receipt designs, so nothing has to be configured before the first receipt.
