Scan Barcode

MailCode for each new entry

One row per donor — a person, company, foundation or DAF — across every client, built only from gifts in reconciled weeks and imported history, so every figure is money a bank statement has proven. Open a donor for their giving, contact details and notes. Gifts keyed this week join after their week closes.

When a gift looks like a donor already on file but the matcher can't be sure, it starts a new record for the gift and asks here. Review each one and choose: Match puts the new record's gifts on the donor on file (undo any time under Recent Merges), Keep as a New Donor leaves them as two donors for good, Skip leaves it for later. In the dialog, keys M, N and S answer. The most money at stake is first.

Recent Merges

A gift waits for a letter once its week is reconciled and it reaches its client's threshold — one letter per gift. Print a run (letters, envelopes, or a mail-merge file), mail it, then confirm the run as mailed. Letters go to the address USPS standardized; one USPS cannot deliver to waits until you set the donor's mailing address, mail it as keyed, or skip it. A gift backed out by a chargeback before its letter prints leaves the queue on its own. At Finish & Deliver, the week's count is offered for the report's # TY Letters.

This client's runs

Recent Runs

The gifts in a filed week that the client's development staff asked to hear about: major gifts, upgrades, returning donors, organizations, deceased and removal notices. Pick a client and week, check the list, then print the digest (or save it as PDF) and send it on.

Every night (about 4:30 AM Eastern) each reconciled week's gifts are matched to a donor profile: one person, company, foundation or DAF across every client. A strong match (same name and address, email or phone) links on its own; anything weaker gets its own profile and waits as a review pair. After each run, the new pairs a reviewer would call one donor on sight (the rules under Settle Review Pairs) are merged on their own, recorded as automatic and undoable under Review. Nothing a client receives changes. Anyone signed in opens a donor's profile from a donor's name on a gift, or from People. Each sample is a random set of what one rule did, side by side, to check by eye.

Everything entered on the selected day — for end-of-day balancing and verifying a staffer's work. (Client deliverables — the weekly export and report — are filed when an admin finishes a reconciliation. Ask an admin for a filed week's files; the Work Log CSV here is for balancing, not for the client. The Daily Export, the client's daily file, carries submitted and reconciled batches only.)

Every night (about 3 AM Eastern) the app saves each client's submitted work that nobody exported into that client's Drive folder (set on the Clients tab), as CLIENT_DailyExport_YYYY.MM.DD_AUTO.xlsx — the same file the Daily Export button makes, one per client per day keyed. Anything already exported here is never sent again, and anything the backup sent can no longer be exported here, so no gift reaches the folder twice. Open batches wait until they are submitted; the last 7 days are covered.

Built from the audit trail and entry records. Active time is estimated from keying bursts (gaps under 15 minutes count as continuous) — a pacing guide, not a punch clock. Edits and deletions are normal parts of careful work; use rates as conversation starters, not verdicts. The Edits + deletes rate counts the changes a staffer made to entries they keyed themselves; changes to someone else's entries show in the Details table but are left out of the rate.

Details

Day by day

Each week's money moves from the caging account to the client's operating account on the week's transfer date: the week's end plus the client's transfer lag — the Transfer Date the transfer workbook prints. A debit whose memo names its week (CAGE_CPI_09/11/2026-09/17/2026) is paired by that; link any other to its week here. Finishing a later week is refused while an earlier week's transfer is missing, unless an admin holds the week with a reason. Brought in is the week's deposits plus what it declared in transit, for comparison only. Historical weeks are the weeks before the system, as the client's manual transfer workbook filed them (its $ In and $ Out): a record, never owed. One whose money left after the system began is paired with that debit and shows when it moved.

Transfers out paired with no week

Debits out of a caging account, filed as Transfer / Sweep, that neither name a week on the schedule nor were linked to one. Link each to the week whose money it moved.

One row per closed reconciliation. Counts come from the week's register — the same figures as the transfer workbook — and rates from the client profile's dated rate card in effect on each transfer date: (billable − whitemail) × base + whitemail × whitemail rate + TY letters × TY rate.

Issued Statements

A statement is issued once, numbered, and kept exactly as it was sent: the Download is that file, byte for byte. Nothing on it is ever recalculated. A week that closes late, or is reopened and closed again with different figures, goes on the next statement issued, labelled. Only the newest statement standing can be voided; its weeks then bill again.

Treasury Account

Donated stock and some wires land in this custodian account. Its activity is non-caging, and each week has to be reconciled here before the bank account's Finish & Deliver the Week can file that week. Each week, export two files from the custodian's portal for the same dates — the Transactions CSV and the Activity Summary CSV — and upload both. The Activity Summary is the week's statement: it has to begin where the last week ended, and the custodian rows have to account for its contributions, withdrawals and income to the cent. Every row is accounted for too — a gift has its donors keyed (they go out with the week's export as Stock or ACH/Wire), a sale of donated stock names the lot it sold (the realized gain or loss goes on the report), and interest, dividends and fees are ticked.

Stock held before the app

Shares this account already held when its treasury reconciliation began — donated before then, so no stock-gift row here brings them in. Record each once at its gift-date value: the day's high and low share prices (their average is the value, as for every stock gift), or the total value with a note saying where it comes from. A later sale of those shares then links to it — Auto-resolve does it when it is the only fit — and its gain or loss is measured against that value, not the custodian's cost, which is the donor's.

Stock lot ledger

Every lot of donated stock this account has held — each stock gift keyed from a Transfer In, each holding from before the app, and each sale given a typed basis — with every sale against it, from the day the shares came in to the last one sold. The gift-date value is what the books carry; a sale's gain or loss is its proceeds less the gift-date value of the shares sold. Also in the transfer workbook (C-7 Stock Lots).

Treasury reconciliation history

Undo runs newest-first, and a treasury period cannot be reopened while a bank week filed on the strength of it still stands — reopen that bank week first.

Carried Forward & In Transit

Rows whose money and whose week have come apart. A bank row the statement lists but whose ending balance has not taken it yet is carried forward to the week that can account for it. Money the ending balance does count, with no row for it yet, is declared in transit against the system item it settles — an assertion that owes proof, which the next reconciliation collects. When the posting file arrives it supersedes what was waiting for it, so nothing lands twice.

Caged Card Batches vs Stripe

Three ledgers have to agree about the same money: the slips keyed, the cards Stripe charged, and the credit the bank received. The payout files only ever speak for the third, after the fact. Stripe's transaction report speaks for the second the same day the cards are run — so a batch's position can be stated here rather than asserted. Keyed − charged should be $0.00: anything else is a slip keyed but never charged, one charged but never keyed, or an amount typed differently from the amount run. A declined card never appears in any payout file, so its slip belongs in a Bad CC zero batch; re-entering a blurred number is a retype, not a death, and is not counted as one. A card found dead only after its week was filed cannot be pulled out of it, so it is backed out in the week it was found and counted here — a filed week never moves.

Declared Fees Awaiting the Payout File

A declared settlement names the net that will land and, by subtraction from the gross keyed, the fee the processor is keeping. The net is proven by the bank row; the fee can only be proven by the payout file, which arrives days later. Until then the fee on that week's report is an assertion — this is the check. A variance is reported, never enforced: the week it affects is already filed, so reopening that reconciliation is the only thing that can correct it. Once its bank row has posted and the file is in, a settlement also stays here until the payout is matched to that row — match its payout… does it, even when the row's week is already closed. A payout still waiting on that match says so under Outstanding System Items.

Outstanding System Items

Submitted work not yet matched to a bank item. Before finishing, every item here must either be matched to a bank item, ticked confirmed in transit (with an optional note), or given a declared settlement — the amount you expect to land, when the processor's payout report is still days behind the money. A confirmation is recorded with the close and then stands for 4 weeks from the period end it was given on — until then the item keeps it unless it settles, its amount changes, or you withdraw it, so an item still in transit next week needs no second tick. Once it has stood longer, the close asks again, and confirming it again needs a note saying why the money is still on its way. Card money Stripe's charge ledger shows as declined is never in transit: pull the slip into a Bad CC zero batch or back it out. A tick over it overrides the ledger, needs a note, and is recorded with the close.

The green mark means a system record is associated with the bank item. Revenue clears by matching to its system donors; ticking a fee, transfer, or other row records it in the system. When every item is recorded and the balance ties, the reconciliation can be finalized.

Upload the processor payout files while matching: each payout's donors back its bank credit, and the payout fees feed the weekly report. Rows belonging to a payout already reconciled are skipped.

Stripe's transaction report for a date range — the one file that records a card that was attempted. A payout export only ever lists charges that succeeded and already paid out, so a declined slip appears nowhere else and the batch it was keyed into simply never ties. It also arrives first: the cards are run as the slips are keyed, so the real fee and net are known days before the payout reaches the bank. Stripe leaves the Transfer column empty until it assigns a charge to a payout, so pulling the same range again later is how a charge learns which payout carried it — re-uploading is expected and safe.

System vs Bank