Give Manual Donations - WordPress Plugin

Give Manual Donations Guide: How to Record Donations Manually in GiveWP

Give Manual Donations is meant for situations where a donation has already been received outside the standard GiveWP form, but still needs to be properly recorded on the site. That might be a bank transfer, a check, a cash contribution collected at an event, a payment processed by staff through an external terminal, or a corrected entry added after speaking with a donor. This guide focuses not on a promotional overview of the add-on, but on the actual workflow: where to add a manual transaction, which fields matter most, how to connect the record to the right donor and form, what to verify in reports, when to enable notifications, and how to troubleshoot common issues.

An important principle: Manual Donations does not replace a payment gateway and does not charge a donor's card. The add-on creates or updates a donation record inside GiveWP. That means the administrator needs to know in advance where the money came from, which status to assign, which donor is tied to the payment, which form or campaign should receive the amount, and which notifications are safe to send.

This guide is useful for nonprofit site owners, WordPress administrators, nonprofit accounting staff, and developers configuring GiveWP for a team. We will go from preparation and installation to a practical event-based workflow, result verification, troubleshooting, and a comparison with similar solutions.

What Problem Manual Donations Solves in GiveWP

A standard GiveWP form is designed for public donations: a visitor opens the page, chooses an amount, enters their details, completes payment, receives confirmation, and the site saves the transaction. Manual Donations serves a different use case. It is meant for cases where the action is performed not by a visitor, but by a staff member inside the WordPress admin panel. The staff member already knows the amount and the source of the funds, so they create the record manually and decide how it should appear in the tracking system.

This matters most for organizations that receive donations through multiple channels. Some people donate online through a form, some send money by bank transfer, some bring cash to an event, and a recurring donor may ask a staff member to process a contribution after a phone call. If those payments remain scattered across separate spreadsheets or systems, GiveWP reports stop reflecting the real picture. Manual Donations helps bring those disconnected payments into one donation log.

What Exactly Gets Added to the System

When creating a manual donation, the administrator selects the GiveWP form, amount, donor, status, payment method, date, and any additional details. Depending on the setup and installed add-ons, related form fields, notes, recurring donation options, and email notifications may also be available. The finished record appears in the donation list, the donor profile, and GiveWP reports, and if the right status is selected, it may also affect fundraising statistics.

Because of that, manual entry should be treated as an administrative record of a known financial event. The plugin should not become a casual way to create successful test payments in a live database "just in case." For testing, it is better to use a separate test environment or the payment gateway test mode, if that test mode is specifically needed to validate payment behavior.

When Manual Donations Is Especially Useful

• The organization receives a check or bank transfer and wants the amount reflected in a specific donor's history.
• The team runs a fundraising event and enters the collected amounts afterward, either by participant or in batches.
• A staff member takes a donation over the phone and needs to assign it to the correct fundraising form.
• You need to restore a record after a migration or manual reconciliation without importing a large CSV file.
• You need to create a donation tied to an existing recurring subscription so GiveWP matches the actual incoming payments.

When It Is Not the Best Tool

If you need to move hundreds or thousands of historical transactions, manual entry will be slow and error-prone. In that case, a donation import or a migration workflow makes more sense. If you need to accept offline payments directly through a public form, the built-in Offline Donations workflow is closer to that use case: the donor submits the form themselves, receives instructions, and the administrator later confirms the payment. Manual Donations works from the other side of the process - the record is created by a staff member in the admin panel.

Quick reality check: if the money has not been received yet and the donor still needs to complete the form, this is not a Manual Donations use case. If the funds have already been received or confirmed and the record needs to be entered into GiveWP, this add-on is a good fit.

Who the Add-On Is For and Which Limits to Consider Up Front

Give Manual Donations fits well into the workflows of small and midsize nonprofits, foundations, educational projects, churches, local communities, and any site that uses GiveWP as its central donation tracking system. Its main value is not a nice-looking button, but data discipline: a manual payment gets a date, status, form, donor, and a clear trace in reports.

The add-on is especially useful when the team already has a clear payment confirmation process. For example, accounting sees a bank transfer, sends the administrator the amount, donor name, and purpose of the payment, and the administrator creates the record in GiveWP. After that, the campaign manager sees updated statistics, and the support team can open the donor profile and understand the contribution history.

Good Fit For

• Teams already using GiveWP that want to track online and offline donations in one place.
• Organizations handling phone donations, bank transfers, checks, and cash collected at events.
• Administrators who need to correct individual records without running a bulk import.
• Sites where donor history and reporting matter more than a simple list of form submissions.
• Projects using paid GiveWP add-ons that want to connect manual records to more advanced workflows, where that combination is supported.

May Not Be a Good Fit

• Sites that do not use GiveWP: Manual Donations is an add-on for GiveWP, not a standalone donation system.
• Teams that need to migrate an old database in bulk: that is better handled through import tools, not by creating every record manually.
• Projects where staff should not have access to financial data inside WordPress.
• Use cases where cards need to be charged automatically or a payment gateway must be triggered. A manual record does not replace real payment processing.
• Sites without a reliable reconciliation workflow. If staff choose statuses and forms arbitrarily, reports will become unreliable very quickly.

Limitations Worth Aligning on with Your Team

The first limitation involves statuses. If a staff member accidentally saves a manual donation as completed, fundraising stats may show money that has not actually been confirmed yet. The second is notifications. Manual Donations can send emails to the donor and administrator, but that action needs to fit the situation. It is not always appropriate to send a receipt immediately: sometimes the payment is still being reconciled, and sometimes the donor has already received a separate confirmation.

The third limitation is access control. Manual records involve personal donor data and financial reports. For that reason, only staff who are genuinely responsible for donation tracking should be allowed to create and edit them. In WordPress, that should be enforced through roles and capabilities, not informal trust.

What to Check Before Installation

Preparation looks simple, but this is where future mistakes usually start. Manual Donations works inside the existing GiveWP structure, so first review the foundation: forms, donors, payment methods, emails, reports, and user roles. The clearer your starting rules are, the fewer manual fixes you will need later.

GiveWP Must Already Be Installed and Working

Manual Donations is an add-on for GiveWP. First, make sure the core GiveWP plugin is installed, activated, and already has at least one working donation form. Open the form page on the site, confirm that it displays correctly, and check that the donations and donors sections are available in the admin panel. If the base form is not working, manual records will not solve the problem - they will only add confusion.

On a live site, it is wise to create a backup before installing a new add-on. This is not because Manual Donations is inherently dangerous. It is simply that any extension interacting with financial records, donor profiles, and email notifications should be introduced through a predictable process: backup, install, verify, then hand it over to the team.

Forms and Campaigns Should Have Clear Purposes

A manual record is attached to a specific form. If the site has several similar forms named "Donate," "Donation," and "Support," it will be hard for staff to choose the right one. Before launch, clean up the form names so they work operationally: for example, "Annual Fund," "Event Sponsorship," or "Emergency Campaign." Even if visitors see a different public-facing label, the team should be able to tell at a glance where a payment belongs.

If the site uses fundraising goals, reports, or form-based segmentation, selecting the wrong form may not be obvious right away. The donation will save, but the numbers will end up under the wrong campaign. Before the first manual entry, create a short internal reference guide that explains which forms are used for which types of donations.

Donors, Statuses, and Payment Methods

Decide how the team will search for or create donors. In the Manual Donations documentation, the donor is a required part of the record: you can select an existing user or donor, or add a new one based on the data the organization already has. For accuracy, do not create a duplicate if the donor already exists. Matching email addresses, different name variations, and outdated records can quickly break the contribution history.

Statuses also need to be aligned in advance. For a confirmed payment, a completed status usually makes sense. For a record that still needs reconciliation, a more cautious status is more appropriate. Do not choose a status by habit alone - think about how it affects reports and internal review.

In Manual Donations, the list of payment methods comes from the options available in GiveWP. That is helpful for tracking, but it requires discipline. If a staff member selects "Stripe" for a bank transfer that arrived through actual banking details, the payment-method report becomes useless. For offline channels, decide ahead of time which option will represent checks, cash, bank transfers, or any other confirmed source.

Email and Global Notification Rules

Manual Donations lets you choose whether to send notifications to the donor and the administrator. But those emails do not depend on that checkbox alone. GiveWP also has global email settings, templates, notification states, and WordPress mail delivery. If a global email is disabled, a local attempt to send it may not do what you expect. Before launch, run at least one real test: create a safe test record on a copy of the site or in a test environment, enable the relevant notifications, and confirm that the email is actually delivered.

Practical rule: a manual donation should still appear in reports even if no email is sent, but an email should never go out by accident. Set up your notification rules first, then give staff access.

Installation and the First Post-Activation Check

Installation depends on how your team gets GiveWP add-ons onto the site, but the overall process follows the standard WordPress pattern: upload the add-on ZIP, activate it, and confirm that GiveWP now offers a way to create manual donations. This guide intentionally does not cover purchasing, license keys, or obtaining the paid version. What matters here is having a working add-on on the site and validating its functionality safely.

General Installation Flow

1. Make sure the core GiveWP plugin is active and the site opens without errors.
2. In the WordPress admin panel, go to the plugin installation screen and upload the add-on ZIP file.
3. Activate the plugin and return to the GiveWP sections.
4. Verify that the option to create a new manual donation record is available.
5. Open the donations list and confirm that the GiveWP interface is working without warnings.

After activation, do not start migrating real payments immediately. First create one safe test record with a clear note attached to it. That record is there to validate the form, donor, status, payment method, emails, and reports. If your live site does not allow test financial entries, use a staging copy or a pre-approved internal procedure for removing test data.

Where to Find the Manual Donation Screen

The official documentation describes two entry points: the New Manual Donation item in the WordPress admin bar and the option to create a record from the GiveWP donations section. In modern installations, the labels may vary slightly depending on the GiveWP version, admin language, or interface changes, so focus on the meaning rather than the exact wording: you need the screen where an administrator creates a new donation record from the admin panel rather than through the public form.

If you do not see that option, do not assume the plugin is broken. First check whether the add-on is activated, whether core GiveWP is active, and whether the current user has enough permissions. A user with a restricted role may still see regular WordPress pages but have no access to GiveWP financial sections.

The First Test Record

For the first check, choose a simple donation form, an existing test donor or a new test profile, a small amount, a safe status, and an obvious payment method. In the note, say that this is a Manual Donations test and indicate where the payment was supposed to come from. Save the record and immediately review three places: the donations list, the donor profile, and the form-level reporting. If you enabled notifications, check email delivery separately.

A good outcome looks like this: the record appears in the list, is linked to the correct form, shows the correct amount and status, appears in the donor history, and changes the statistics only in the way the team expects. If the amount ends up under the wrong form or an email goes to the wrong recipient, stop all further manual entry and fix the rules first.

Detailed Setup After Installation: A Working Profile for Manual Tracking

Once Manual Donations is installed, many teams are tempted to start entering real donations right away. It is better to define a working profile for manual tracking first. This is not a separate page full of toggles, but a set of agreed decisions: which forms to use, which statuses mean confirmed, which payment methods map to real-world channels, when to send emails, how to write notes, and who verifies the outcome. You can document that profile as an internal procedure and test it with a single sample record.

The idea is simple: everyone on the team should create similar records in the same way. If one person assigns a bank transfer to the "General Fund" form, another assigns it to an event form, and a third picks the first payment method they see, GiveWP reports may look tidy on the surface but still be wrong in practice. Manual Donations cannot infer what a line on a bank statement means. It provides the interface, but the team provides the accuracy.

Step 1. Build a Map of Forms and Purposes

Start with the GiveWP forms. For each form, write down which kinds of manual donations should be assigned to it. For example, the annual fund form accepts general donations of any kind, the event form accepts only funds related to that event, and the emergency campaign form accepts transfers clearly designated for that campaign. If your team has gray areas, settle them before data entry begins, not while someone is saving a record.

Your form map should stay short. There is no need to document every form setting. The admin-panel name, the public campaign purpose, and the selection rule are enough. The simpler the rule, the fewer mistakes volunteers and support staff will make.

If your setup uses the newer GiveWP campaigns or separate forms for different funds, adapt this table to your current structure. The key point is not to confuse "form as a public page" with "form as an accounting container." For Manual Donations, the second meaning matters most.

Step 2. Define Statuses for Confirmed and Uncertain Payments

A status is not a decorative label. It affects how the record is treated in lists, reports, and goals. That is why Manual Donations setup should begin with a decision about which statuses belong in your manual workflow. A confirmed bank transfer needs one approach, an expected but not yet deposited check needs another, and a test record needs a third. If everything is saved as completed, the team may overstate fundraising totals. If everything is left pending, reports will not show the actual money received.

Run a test with two safe records in a non-production environment or on a pre-approved test form. Save one with the status you consider final and the other with a pending status. Then check the donations list, the form report, and the public goal if one is displayed. That gives you a view of how your specific GiveWP setup behaves, not just an abstract description of status names.

Typical Status Approach

• A confirmed payment gets the status that contributes to financial totals and campaign goals.
• A payment that still needs reconciliation gets an intermediate status and should not create the appearance of a finalized contribution.
• A test record is marked with a note and either deleted or excluded from reporting under your internal rule.
• A corrected record gets a new note so it is clear who changed the data and why.

Do not tie status only to the payment channel. A bank transfer can be confirmed or pending, a check can be received or not yet deposited, and cash can be counted or still under review. The status should answer the question, "Can this donation be treated as finalized in GiveWP?" not simply, "Where did the money come from?"

Step 3. Create a Payment Method Dictionary

In Manual Donations, the payment method is there for tracking and filtering. It does not mean the add-on is actually running a live transaction through the selected gateway. That is why your channel list needs to be clear to everyone working with records. If you use Stripe and PayPal for online donations, do not assign those options to manual check entries just because they already appear in the list. Otherwise, your payment-method report will stop distinguishing real online channels from offline revenue.

A good channel dictionary answers two questions: which channel to select, and what note to leave. For example, for cash collected after an event, you might use a general offline channel and add the note "event cash sheet." For a bank transfer, you might use a dedicated payment method if your settings provide one and reference the bank statement line in a safe way. For an external terminal, use the channel your team reserves specifically for those confirmed payments.

How to Validate the Channel Dictionary

1. Create one test manual record for each channel.
2. Open reports or the donations list and see whether those records are easy to filter.
3. Check that manual payments are not being mixed with regular online transactions.
4. Ask a second staff member to choose the channel based only on the situation description.
5. Adjust the names or internal instructions if the choice turns out to be ambiguous.

If the GiveWP interface does not let you configure channels as precisely as you would like, do not try to compensate with unpredictable notes. It is better to keep a small set of clear options and store the extra detail in an external reconciliation process. Manual Donations should remain a usable tool, not a warehouse for every accounting detail.

Step 4. Set Up a Notification Matrix

Notifications are one of the most sensitive parts of manual entry. Saving a record in the admin panel is one thing; sending an email to a person on behalf of the organization is another. Before launch, create a simple matrix: when a donor email should be sent, when it should not, when only the administrator should be notified, and when the record should be created with no email at all.

For a confirmed donation where the donor expects a GiveWP receipt, an email is usually appropriate. For an internal transfer of an old historical record, an email may be inappropriate because the donor either received confirmation long ago or is not expecting fresh communication at all. For tests, emails should go only to test addresses. For recurring workflows, emails require extra caution so the donor does not receive a message that looks like a new payment or a subscription change.

After setting up the matrix, review the email template itself. Its wording should not mislead the donor. If the payment was accepted in cash, the email should not read as if the donor just completed an online payment. If the record is being created retroactively, the date shown in the email should still make sense to the recipient.

Step 5. Decide Who Is Allowed to Create and Correct Records

Manual donation entry involves personal and financial data. Access should not be given to everyone who knows how to use WordPress. A safe minimum is to allow creation rights to staff who enter confirmed data, while keeping final correction rights or status changes with a more responsible user. The exact setup depends on your WordPress roles and the GiveWP capabilities available in your environment.

If the organization works with volunteers, consider a staging process outside the site: volunteers fill in a reviewable spreadsheet, and a designated staff member transfers the records into GiveWP. It is slower, but it reduces the risk of someone casually seeing extra donor data or changing a status by mistake. Manual Donations is convenient for manual entry, but it does not replace an access policy.

Step 6. Define a Rollback Rule

Every manual operation should have a clear rollback path. If a record is created by mistake, the team should know whether to edit it, change its status, leave a note, or delete it under an internal rule. In financial data, deletion is not always the best option because it removes the trace of the mistake. Sometimes it is better to change the status, add a note, and create a corrected record. But that depends on the organization's requirements and accounting process.

For Manual Donations, a good rollback process starts with documentation: what was entered, what turned out to be wrong, who found the issue, and how it was corrected. Even if GiveWP lets you edit a record quickly, do not turn that into a silent change. Months later, the note may be the only thing that explains why the amount or date was changed.

The Core Model: Record, Donor, Form, and Status

The most important part of setting up Manual Donations is understanding the relationship between four entities: the donation record, the donor, the form, and the status. If even one of them is chosen incorrectly, the donation may look saved but still be functionally wrong. It may appear under the wrong campaign, in the wrong donor history, or in the wrong financial state.

The Form Defines the Donation Context

In GiveWP, a form does more than display a public input field for visitors. It also acts as the container for settings, goals, reporting, and fundraising behavior. That is why, during manual entry, the form answers the question: "Which fundraising effort does this amount belong to?" If the donor gave money to a specific campaign, choose that campaign's form. If the transfer was general, use the pre-agreed general fund form.

You do not need to create a separate form just because the donation was entered manually. The form should reflect the purpose of the funds, not the input channel. The channel is better captured through the payment method, note, or internal classification available in your GiveWP setup.

The Donor Connects the Payment to a Person's History

A manual record without the correct donor loses part of its value. GiveWP is designed to maintain donor history, so before creating a new profile, check whether an existing donor already matches the same email address or similar details. If you create a duplicate, person-level reports become incomplete: the same donor will appear as two separate contacts.

When creating a new donor, enter only the information that is truly needed and lawfully obtained. Do not move unnecessary personal details from internal documents into WordPress if they are not used for donation tracking or communication. The less extra data you store, the easier it is to keep things organized and meet privacy requirements.

Amount and Date Shape the Financial Picture

The amount should match the confirmed funds received. If the payment arrived net of fees from an external service, decide in advance what GiveWP should store: the full donation amount, the amount actually received, or the pre-fee amount. That is an accounting decision, not just a plugin setting. Manual Donations only records the rule you chose.

The date matters just as much. If you enter a donation retroactively, period-based reports will change. That is normal during reconciliation, but the team should understand the effect. If you are entering many donations after an event, work from a list and review dates in batches, otherwise some entries may fall into the wrong month or reporting period.

The Status Determines Whether the Record Counts as Final

The status of a manual record should reflect the actual state of the payment. If the funds are confirmed, a completed status helps reports show the correct outcome. If the payment is still pending reconciliation, choose a status that does not create the false impression of a finished donation. Status names and behavior depend on GiveWP and your site configuration, so before real-world rollout, test one record and see how different statuses show up in the donations list and reports.

An incorrect status is one of the most frustrating problems because the record looks fine but changes the numbers. A good practice is to decide who is allowed to move a manual donation into its final state. If a volunteer performs the initial entry and accounting confirms it later, the status should support that workflow.

Payment Methods, Notifications, and Internal Notes

Once the core fields are in place, the details start to determine the quality of your records. The payment method helps explain where the money came from, notifications govern communication with the donor and the team, and notes explain why the record was created manually. These fields should not be filled out mechanically - they are what make a manual donation traceable a month later, at quarter end, or during a campaign audit.

Using Payment Method as a Reconciliation Channel

Manual Donations displays the payment methods available in GiveWP. For manual entry, that does not mean the payment is actually processed through the selected gateway. It is better understood as a classification of the channel through which the money already arrived. If the site uses Stripe and PayPal for online donations, but cash is marked with those same methods, channel reports stop reflecting reality.

It is better to prepare clear options in advance. For offline revenue, you can use GiveWP's existing offline setup if it fits your process, or a separate method the team understands consistently. The important thing is not to confuse "how the money came in" with "how the record was created." A manual record may describe a bank transfer, check, cash payment, or externally processed payment, but the fact that it was entered manually is not itself a payment method.

When to Send Donor Notifications

The official Manual Donations documentation shows that donor notifications can be sent. In practice, this field needs careful handling. If the donation has already been confirmed through another channel and the donor is expecting a GiveWP receipt, then the email makes sense. If the record is being entered for internal reconciliation or testing, the email may just create noise. If the donor did not provide an email address for that kind of communication, sending it may be inappropriate.

Before enabling delivery, review the GiveWP email template. It should contain the correct organization name, donation details, and wording or links that fit a manual-entry workflow. Do not leave language in place that suggests an online form payment if the donor actually sent a bank transfer or submitted a check.

Administrator Notifications

An administrator email is useful when one staff member creates the manual record and another oversees it. For example, a volunteer enters donations after an event, and accounting receives the notifications and reconciles the entries against the bank statement. But if the same person is entering dozens of records, a stream of emails may become a distraction. In that case, it is better to rely on the donations list, filters, exports, and the internal review process.

Notes as Proof of Where the Record Came From

Notes are often underestimated, even though they can explain a record without extra back-and-forth. A good note answers three questions: where the data came from, who confirmed the payment, and whether there is a link to an external document. For example: "Bank transfer confirmed by accounting, campaign: Spring Fund, reference: statement line 42." This is not public donor-facing content, but an internal cue for the team.

Do not store full card numbers, unnecessary passport or ID details, document scans, or other sensitive information in notes if GiveWP does not actually need it. If your organization requires strict audit handling, keep external documents in a separate secure system and store only a neutral reconciliation reference in GiveWP.

Manual Donations and Additional Form Fields

One of the most important practical details with Manual Donations involves form fields. In GiveWP documentation for Form Field Manager, custom fields are described as appearing on the Manual Donations screen after the transaction is completed. That matters because if the team expects to see every extra field at the exact moment the manual record is created, they may assume the integration is broken. In reality, the workflow may be two-step: first create the donation record, then open its details and fill in the additional data.

This is especially noticeable for organizations that track more than just amount and name - for example, payment purpose, department, comment, donor type, or an internal campaign code. If those fields matter for reporting, verify in advance exactly where they are edited after the manual donation is created and who is responsible for filling them in.

How to Build a Safe Process with Additional Fields

1. Create or open the GiveWP form that already includes the required custom fields.
2. Create a test manual record through Manual Donations.
3. Open the newly created donation in the admin panel and check which fields are available in its details.
4. Fill in the extra fields, save the record, and verify whether the data appears in the required reports or donor profile.
5. Document the internal workflow for staff: which fields are filled in before saving and which are completed afterward.

If certain fields are strictly required before the record is saved, Manual Donations may force a process adjustment. Instead of trying to push the interface into something it is not, it is usually simpler to split the work: the administrator creates the base record, then immediately opens the details and completes it. That takes a little longer, but it stays compatible with documented GiveWP behavior.

Which Fields You Should Not Add Without a Clear Need

Custom fields should support tracking, not turn manual entry into a long questionnaire. For donations, useful fields often include internal source, related event, payment purpose, or a short comment. Fields tend to fail when staff cannot fill them in reliably, such as "donor mood," "likelihood of repeat giving," or "interest type" without clear rules. Data like that quickly becomes subjective and does not help reporting.

Also verify which fields may appear in donor emails or public-facing data. If a field is meant only for internal tracking, it should not accidentally end up in a notification template. Before launch, create a test record and read the email carefully from the recipient's point of view.

Working with Recurring Donations: When a Manual Record Belongs to a Subscription

Manual Donations supports recurring donation workflows if the matching GiveWP add-on is installed on the site. This is one of the most sensitive modes because it is not just about a single entry - it involves a subscription, a parent payment, and the payment provider profile. A mistake here can distort the history of a recurring donor.

Use this workflow only when you clearly understand what actually happened. For example, a payment in a recurring subscription may have been processed externally but still needs to be attached to an existing subscription in GiveWP. Or you may be creating the initial record that should become the parent of the recurring history. If the staff member is unsure, it is better to reconcile the information with the payment system and the GiveWP documentation first.

What to Check Before Creating a Manual Recurring Record

• Whether the Recurring Donations add-on is installed and active.
• Whether the required subscription already exists or an initial record needs to be created.
• Whether the donor, form, amount, and interval match the actual data.
• Whether there is an external profile or payment identifier needed for reconciliation.
• Whether the team understands which emails will go to the donor after saving.

If the recurring subscription already lives in the payment service, Manual Donations should not create the illusion that GiveWP is controlling something it does not actually manage. The manual record should reflect a real event and be tied to the correct history. When in doubt, it is safer to leave a detailed note and avoid touching the subscription until everything is verified.

The Parent Record and Subsequent Payments

Recurring donations usually involve an important distinction between the first record and the payments that follow. The first record may establish the start of the subscription, while later payments need to stay linked to it. Manual Donations, when used together with Recurring Donations, can help represent those events inside GiveWP, but it requires careful attention to profile fields, status, and date.

After saving, do not check only the donations list. Open the donor profile and the subscriptions section if it is available in your setup. Make sure the donation is attached to the correct recurring history rather than appearing as a separate one-time payment. The goal of this check is not just to see the amount, but to confirm the correct relationship between the donor, the subscription, and the payment.

When It Is Better Not to Touch a Recurring Workflow Manually

If a recurring donation is supposed to be charged automatically by a payment gateway, creating a manual record does not replace the gateway. Do not use Manual Donations to "fix" a broken subscription unless you understand the cause. First review the status at the payment provider, the GiveWP logs, the emails, and the actual movement of funds. A manual record can be part of correcting the accounting trail, but it should not be used to hide a failed payment integration.

Practical Workflow: Entering Donations After a Fundraising Event

Imagine a typical case. An organization has run an offline event where guests could give cash, hand over a check, or show proof of a bank transfer. The site already has a GiveWP campaign for that event, and the team wants the final amount reflected in campaign stats, donor history, and reports. Manual Donations is well suited to this, as long as the team works from a careful, verified list.

Goal

You need to enter several confirmed donations into GiveWP so that each one is tied to the correct campaign form, donor, payment method, and event date. After entry, the campaign manager should be able to open the form report and see the updated total, while support staff should be able to find the donation in the donor profile.

Preparation

Before entering anything, prepare a spreadsheet or list with the minimum required fields: donor name, email address, amount, date, incoming channel, confirmation, and note. If a donor does not have an email address, decide how the team will handle creating or not creating a GiveWP record while staying within the site's data rules. Do not invent email addresses just to make the donor profile look complete - that will damage data quality.

Check the campaign form. It should be active, clearly named, and not easily confused with other forms. If the site uses a fundraising goal, note the starting amount before entry begins. That makes it easier to verify the outcome after several records have been added.

Entry Steps

1. Open the manual donation creation screen in GiveWP.
2. Select the campaign form the payment belongs to.
3. Find an existing donor or create a new one from confirmed data.
4. Enter the amount exactly as it should be tracked under your financial rules.
5. Select either the event date or the actual payment date, depending on your internal policy.
6. Choose the payment method that matches the channel: check, cash, bank transfer, or another available option.
7. Select the status that reflects whether the payment is confirmed.
8. Decide whether to send an email to the donor and administrator.
9. Add an internal note referencing the row in your list or another safe reconciliation identifier.
10. Save the record and immediately open its details.

After each entry, you do not need to recheck every report, but the first two are worth reviewing carefully. That will tell you whether the form selection is correct, whether emails are being sent unexpectedly, and whether donor duplicates are being created. After that, you can continue working through the list.

Verification After a Batch of Entries

Open the donations list and filter by form, date, or payment method if those filters are available in your setup. Compare the number of rows and the total amount against the source list. Then open the campaign report and check whether the funds raised changed as expected. If the site uses a fundraising goal, the public form page should show updated progress only after the records receive a status that counts toward totals.

Also review at least one donor profile. The new entry should appear there, and the history should not split across similar-looking contacts. If the same person appears twice, stop entering new records and decide how donor merging or correction should be handled within GiveWP's capabilities.

A Common Email Pitfall

If you send emails after an event, a donor may receive several notifications in a row or a message with an unexpected date. Before bulk entry, align on the message type: will it be a receipt, a thank-you note, or an internal-only record with no email at all? For larger events, it is sometimes easier to enter all records without donor emails first, then send a separate thank-you campaign from the communication tool your team normally uses. But if a GiveWP receipt is legally or operationally required, testing that email is mandatory.

Workflow summary: Manual Donations works very well after an event when the team has a confirmed list, one shared status rule, and a clear way to verify the outcome in GiveWP.

How to Verify the Outcome in Reports, Goals, and the Donor Profile

A saved record is not the end of the work. A manual donation needs several checks because it affects multiple layers of GiveWP. The administrator sees a row in the donations list, the fundraiser watches campaign progress, accounting reconciles the payment method and date, and donor relations staff open the person's profile. A mistake may show up in only one of those places.

Check the Donations List

The first level is the donations list. Verify the amount, donor, form, status, date, and payment method. If the list supports quick actions or filters, use them during reconciliation. The record should be understandable without opening its details: a staff member should be able to tell that this is a manual entry for a specific channel, not a regular online payment.

Check the Donor Profile

Open the donor profile and make sure the donation landed in the correct history. This matters especially for recurring donors. If the record was attached to a new duplicate instead, future communication decisions may be based on incomplete information: the team will not see the full lifetime amount, giving frequency, or past interactions.

Check Reports and Goals

GiveWP reports should reflect manual records according to the selected status and form. If the amount does not appear where you expect it, check the status, date, and chosen form. If the amount appears but should not count toward fundraising totals, the status is probably too final or the record was assigned to the wrong campaign. For fundraising goals, check the public form page after clearing the cache if the site uses page caching.

Check Emails and Logs

If notifications were enabled, verify actual delivery. It is not enough to see that the box was checked. WordPress may fail to send email because of mail configuration, an SMTP plugin, hosting restrictions, or a disabled GiveWP template. If the message matters, review mail logs or a test inbox. For administrators, it can also be useful to review GiveWP logs if they are available in your environment and help trace events.

How to Organize the Workflow Safely for Your Team

Manual Donations becomes useful not just because of the interface, but because of the rules around it. If every staff member enters manual donations in their own way, even the best screen will not save your reports. That is why, after the technical setup, it is worth writing a short internal procedure.

Separate Entry from Approval

In small teams, one person often does everything: receives payment information, creates the record, checks the report, and sends the email. That is fast, but it increases the risk of mistakes. If possible, split the roles. One staff member enters records from a confirmed list, and another verifies the amounts and statuses. Even spot-checking the first ten entries meaningfully reduces risk.

Use a Standard Note Format

A good note format makes it easy to trace where a record came from. For example: "Source: event cash sheet; confirmed by: Maria; reference: row 18; email receipt: no." The format can be in English or another language - what matters is that the team uses it consistently. Do not turn the note into a long narrative. It should stay short, verifiable, and safe.

Do Not Use Code When Process Solves the Problem

For Manual Donations, custom PHP or JavaScript is usually unnecessary. Most issues are solved through GiveWP settings, roles, email behavior, forms, and internal discipline. If it feels like you need a snippet to change statuses or emails automatically, check the official GiveWP documentation and support resources first. Modifying financial records without confirmed hooks can create more problems than it solves.

A safe improvement that requires no code is an internal review template. You can keep it in your team documentation and use it before saving each manual record:

Before saving a Manual Donation:
1. The form matches the purpose of the payment.
2. The donor was found without duplication or created from confirmed data.
3. The amount and date match the external confirmation.
4. The payment method reflects the actual incoming channel.
5. The status does not overstate the fundraising total.
6. Notifications are enabled only when an email is truly needed.
7. The internal note explains where the record came from.

This kind of checklist does not touch site code, but it significantly lowers the risk of inaccurate reports. If your team works with volunteers, a printed or pinned instruction is often more useful than an unstable technical customization.

Useful Video Walkthrough for Manual Entry

For a visual walkthrough of the interface, the official GiveWP video on Manual Donations is useful. It serves the practical intent of "how to create a manual donation in GiveWP" by showing where the action lives, which fields are filled in, and what the record creation process looks like. Use the video as a companion to this guide, not as a replacement for your internal rules around statuses, forms, and notifications.

As you watch, pay attention to three things: how the form and donor are selected at the start of the workflow, how the amount and payment method are configured, and how the record is saved and then verified. If the interface on your site looks different, compare the workflow rather than the exact pixels: WordPress admin panel, GiveWP screen, new donation record creation, and a verifiable outcome.

When Give Manual Donations Is the Right Choice

Give Manual Donations is worth using when GiveWP already serves as your main donation tracking system and some contributions come in outside the public online form. The add-on is especially useful for checks, bank transfers, post-event cash donations, phone donations, and targeted corrections where the connection to the donor, form, status, and reports really matters.

Before rolling it out in production, review not just the installation but the workflow: who creates records, who confirms statuses, which forms to use, when emails should be sent, how notes should be written, and where the outcome should be checked. If those rules are in place, Manual Donations becomes a clean bridge between outside payments and the GiveWP system. If they are not, manual entry quickly turns into a source of discrepancies.

After setup, create one test record and check the donations list, donor profile, reports, campaign goal, and emails. Only after that should you move on to real data. Once everything is ready, you can download the ZIP package and test the add-on on your WordPress site in a safe workflow.