Donor Management | Entry 34
Yes. An internal gift-entry experience can give staff one consistent place to record checks, cash, bank transfers, phone pledges, and other offline donations while keeping them connected with the donor's complete CRM history.
Digital donation pages will never cover every giving situation. Nonprofits continue to receive money and commitments through channels that need a controlled internal entry process.
Without a dependable process, these gifts often end up in spreadsheets, emails, paper notes, accounting software, personal task lists, or unstructured Contact properties. That makes giving history, acknowledgment, reconciliation, and duplicate prevention harder than they need to be.
The right interface should preserve the relationship among the donor, payer, household, organization, campaign, fund, pledge, donation, and payment.
The internal form may collect the donor, payer, amount, date received, payment method, check number or external reference, fund, designation, campaign, appeal, pledge installment, tribute details, anonymity preference, deductible amount, fair-market value, receipt status, deposit status, accounting status, and staff member entering the gift.
That information helps the nonprofit understand and manage the transaction. Card numbers, security codes, bank passwords, online banking credentials, and other payment credentials should never enter ordinary HubSpot forms, properties, notes, tasks, tickets, attachments, or app-card fields.
| Payment method | Information and controls to consider |
|---|---|
| Mailed check | Date received, check number, donor and payer, fund, appeal, deposit batch, acknowledgment, and stages from received through reconciled. |
| Cash | Amount, time, location, event, donor, staff receiver, second verifier, sequential receipt, secure storage, deposit deadline, and reconciliation. |
| Bank or wire transfer | Gross and net amounts, currency, bank reference, sender, donor, transfer fee, fund, accounting reference, and reconciliation status. |
| External processor or terminal | Verified external transaction reference, amount, payer, donor, processor, date, fee, and CRM associations. |
| Phone pledge | Promised amount, fund, schedule, expected payment date, preferred method, restrictions, recognition, and approved follow-up. |
A form can document a cash transaction, but it cannot replace the nonprofit's cash-handling policy. A check also should not appear as fully reconciled revenue simply because someone opened the envelope.
HubSpot's online checkout is not designed for staff to collect buyer payment information orally. A donor who calls can make a pledge, request payment instructions, or receive a secure payment link and enter the credentials personally.
If the nonprofit accepts cards by phone, it needs a processor and workflow approved for card-not-present transactions. An internal form does not remove the processor's fees or PCI requirements. Checks, cash, and transfers may avoid card-processing fees because no card is involved, though other fees and administrative costs may still apply.
Authorized users can manually create HubSpot payment records for payments received or processed outside HubSpot's online tools. This may be useful for checks, cash, transfers, external terminals, payments processed in another system, or corrected historical transactions.
HubSpot can also import multiple payment records and, with Professional or Enterprise subscriptions, create payment records through workflows. Limit who can create, edit, associate, archive, refund, adjust, export, and reconcile these records.
A manual payment can be associated with supported Contacts, Companies, Deals, subscriptions, invoices, and custom objects. A nonprofit may use custom objects for donations, pledges, households, funds, grants, memberships, event registrations, sponsorships, or program participation.
Identify the correct associations before automating record creation. The bank sender, person writing the check, legal donor, household receiving recognition, organization, pledge owner, and program participant may be different.
A custom app card can display the donor's identity, household, recent gifts, active pledges, membership status, current campaigns, approved funds, and outstanding balances before staff enter a new transaction. Opening the tool from the existing CRM record reduces searching and incorrect Contact matching.
New internal donation cards should use HubSpot's current app-card and UI-extension framework. Classic legacy CRM cards are being deprecated and are scheduled to stop rendering on October 31, 2026.
Repeated staff submissions can cause cookie and Contact-association problems, create duplicates, overwrite properties, distort marketing-form reports, or trigger completed-gift automation before a payment has been verified.
A controlled tool should identify the staff user separately from the donor and create repeatable donation or payment records instead of storing every gift directly on the Contact.
Contact properties work well for lifetime giving, first and most recent donation dates, latest amount, preferred fund, or donor status. They do not preserve a complete gift history.
If each entry replaces one field called "Donation Amount," the nonprofit loses individual gift dates, funds, campaigns, methods, refunds, pledge installments, receipts, and accounting references. The internal form should create the appropriate transaction record, while calculations or rollups update summary values on the Contact.
Offline gifts often arrive without an email address, with a shared or outdated email, through a Company, or from a payer who is not the donor. Staff should be able to search by constituent ID, name, address, phone, household, organization, membership number, prior giving, and check information.
The process should let staff select an existing record, review possible matches, create a new Contact, or send an uncertain match for review instead of automatically creating a duplicate.
| Record or status | What it means |
|---|---|
| Pledge | The donor has promised to give. |
| Expected installment | A payment is scheduled or anticipated. |
| Check received | A physical payment has arrived. |
| Manual payment created | The transaction has been recorded in HubSpot. |
| Deposit confirmed | Finance has verified the deposit. |
| Reconciled | The CRM, bank, and accounting records agree. |
| Acknowledged or receipted | The donor received the appropriate communication or required receipt. |
A phone commitment should not create a successful payment, and a full pledge should not be counted as received revenue when only one installment has arrived.
Large, anonymous, restricted, split, foreign-currency, donor-advised fund, stock, refund, reversal, and unidentified transactions may need additional review.
An internal tool can create donation and payment records, associate donors and organizations, update a pledge balance, notify finance, create review tasks, route exceptions, request a receipt, update donor summaries, and begin stewardship.
Use clear stages such as Entered, Awaiting Verification, Verified, Deposited, Reconciled, Acknowledged, Receipted, Refunded, Reversed, and Voided. Completed-donation actions should wait until the appropriate verification is finished.
Finance may need to match the donation, payment, check or transfer, deposit batch, bank statement, accounting entry, fund, general-ledger code, receipt, and pledge installment.
Define which system is authoritative for the donation amount, payment and deposit status, restriction, accounting classification, refund, reversal, bank reconciliation, and official reporting. "Entered in HubSpot" should not automatically mean "reconciled by finance."
Functionality depends on HubSpot subscription, payment and workflow permissions, custom-object access, app-card architecture, UI extensions, payment processor, PCI requirements, accounting integration, donation and pledge architecture, association limits, receipt requirements, user permissions, privacy policies, and staff capacity.
Before launch, confirm donor matching, duplicate prevention, controlled funds and campaigns, separation of pledges from payments, verification before acknowledgment, correct CRM associations, restricted manual-payment permissions, accounting reconciliation, secure phone-payment handling, migration from legacy CRM cards, and ongoing ownership.