When a non-recurring online donation is made and the transaction completes with a "credit card declined" result, the congregant must be the one to resubmit it. There is no impact to MinistryPlatform.

In MinistryPlatform, there are a few default records that you should never edit because they are the "catch-all" records. For example, any donation made that doesn't match a contact in the database is assigned to the Default Donor record and the Default Contact record defined in your configuration file. Your best approach for investigating how it happened is to check the Audit Log on the record that has all the donations. Most likely, you will see that a user changed the Default Donor record from the Default Contact and onto a real person (the name you're seeing everywhere).

The first step to correcting this is to revert this Default Donor record to the correct name so you can tell which donations are assigned to the default contact. Following that change, you can have your staff assign donors to donations via the Batch Manager Tool or the Assign Donor tool.

If your security rights allow you to do this, you can technically do this by editing the Donation Distribution records of the Donation record which you access from the Donations page in MinistryPlatform. However, this is a violation of our recommended approach to correcting entries with an accounting consequence. Here is what we recommend:

1. If your change has an accounting consequence, make an adjusting entry even if the donor sees this.
2. If your change has no accounting consequence, then it is fine to carefully edit the Donation or Donation Distribution record.

Here is how to categorize issues:

• Any change that affects the amounts of a donation has an accounting consequence. Make an adjusting entry.
• Any change that affects the program(s) to which the donation was distributed (Donation Distribution record) or the allocation of that distribution has an accounting consequence. Make an adjustment.
• A change that affects the event (project) to which a donation was distributed (Donation Distribution record) may have an accounting consequence.
• Other changes are less likely to have an accounting consequence. These include making a note or crediting a pledge.

Now, it is up to your church whether it is acceptable to edit the donation distribution(s) of a donation whose batch has been finalized and the deposit exported. Technically, if your security rights allow it, you can change the program of any distribution manually. This fixes the problem on the donor statement. You could then go and make an adjusting entry in your accounting system. It's not up to ACS Technologies to prevent you from doing this or to help you in this effort.

Perform a search using the ARB subscription code. This code is in the Online Donation Information section on the main page of a donation if it was made online and set up as a recurring gift. Find one donation in the series, copy the subscription code, then paste it into the search box on the donations data grid. This finds every item in the subscription, regardless of what other data about the Donations might have changed, making them harder to find with normal searching methods like date or name.

Donation amounts don't show if the donation is marked as non-cash or if the donation is distributed to a program that has Tax Deductible set to No. The exception is if the Accounting Company record has List Non-Cash Gifts set to Yes.

Research is needed to determine what may be the cause. Here are some questions to ask:

• Is it assigned to the correct donor?
• Is it in a batch?
• Is that batch finalized?
• Does the Donation record have Distribution records?
• Is the donation date within the time frame of the statement?
• Is the donation a non-cash or asset donation?
• Is your accounting company set to list non-cash gifts?
• Is it distributed to a program that is not tax deductible?

If the donation displays on printed statement reports, but not in the My Contribution Statements widget, then check that the Statement Cutoff Date field is earlier than your current Online Giving Through date value in your Accounting Company record.

The Processed field (in the Online Donation Information section) is part of the gateway response information for online giving. You may ignore this field. It would most likely be set to No if the item was part of a series of expected recurring donations (a subscription code), and the Platform does not know whether it processed.

If your staff added an item to a batch or deposit that didn't process at Authorize.net, then this would lead to a review of your process. Determine if your process is checking Authorize.net to verify that items in a batch had been a part of a settlement. Now, if someone did add a donation to a batch and that donation was subsequently discovered to "not have processed", then you have to decide how you want to fix it:

Option 1: Delete the donation and distribution.

Option 2: Treat it like an NSF Donation and reverse it, then batch the reversing entry and record it in your accounting system.

If you use Option 1, then you might need to edit the batch total and deposit total amounts. You also have to decide what to do with your accounting system. Depending upon your internal processes, you may need to make an adjustment to your accounting system to reflect the mistake there. If you take Option 1, remember that subscriptions "automated recurring billing" entries can be canceled by your team. Learn more about changing ARB subscriptions.

The only solution is to have these records restored from a backup, which incurs a cost. A SPoC can contact Support to work with Professional Services.

The statement footer WILL accept basic HTML tags (like <br/> for a return), but it won't accept formatting (like centering, and so on).

Yes, you can find and select future instances of the subscription on the donation distributions with a view, then use the assign feature to carefully change their program.

The field doesn't "do" anything, and it's only set once, in the beginning. If it's a single transaction and processes successfully, it is set to Yes. If it's for a recurring gift and the card processes successfully to get things set up, when the records are all created for the rest of the ARB, all the processed fields are set to No. The contributions department would need to check each donation in the occurrence to see if it went through. The Authorize.net and MinistryPlatform systems never talk again or compare notes after the original transaction (unless someone cancels a recurring gift, in which case they do talk one more time to cancel on both ends).

If you import from a source other than RemitPlus, you should assign the MinistryPlatform contact ID to any new Donor record in the third-party system so it can match during import. When importing from any source, donors might not match due to multiple donor records matching the account or routing information. In this case, after importing, you should click Match Donors. This identifies any donations that match multiple donors.

If it was a one time issue and the remaining recurring gifts will not also decline, treat it like an NSF correction. If a recurring donation is declined for a reason that will continue to be a problem in the future, you should manually modify the ARB subscription.

The Pledge Statement Selected report parameter of "combine family" only includes donation detail for the family if all family members are in the selection.

Create a custom view on the Donations page that filters for the Notes field so you can see the notes all together in the data grid.

The contact ID and donor ID numbers are only visible in the Platform. If you need to communicate an identifying number with a donor, such as a contact ID or envelope number, send the donor a message using the New Message Tool and merge the appropriate fields into the message.

You can handle an overpayment refund with either of these methods:

Using the Batch Manager Tool:

• Create a negative batch for the refund(s).
• Process as a typical manual entry batch but using negative amounts.

Using the Copy Selected Donation actionable report:

• Use the report to copy the donation(s) that need to be partially refunded.
• Change the amount to negative, and also adjust the amounts to the proper portion to be refunded.

Technically, you can point both configuration settings at the same Authorize.Net account, but we don't recommend it. Consider payments and donations as separate sub-ledgers to your general ledger. As such, each sub-ledger transmits data to the accounting system separately. There is not consolidated reporting and transmission of this data across these two sub-ledgers. The data is kept separate in MinistryPlatform and that is not something that will change in our software. We want payments and donations to be in separate database tables.

Now, the consequence of having one Authorize.Net gateway is that you would have deposits that would contain some payments and some donations on your bank account. This would mean that reconciling one deposit on your bank statement could and would involve multiple credits to cash in your accounting system.

Yes, all online giving works this way, as the payment processor treats each as a separate recurring donation. This allows people to cancel or edit one gift without canceling or editing all gifts. People can log in to the My Giving widget and see how it matches the charges made on their credit card or bank statement; in this case, two recurring gifts in My Giving and two charges on their credit card or bank statement.

The Selected Household Donations report has a monthly, quarterly, and annual chart of giving. You can also export qualifying donation distributions from a view and create a pivot table in Excel.

The field might not let you to edit due to security role restrictions. Check to make sure you have appropriate rights and that there isn't field level security on the field. Once you can edit the field, you can find and correct other mismatched pledges. To do this, create a view on the Pledges page that displays gifts for this pledge campaign that still show the incorrect program.

The system is working as expected. The Date Created field is related to the Audit Log, and so the Deposit records in your view with null Date Created values have no "created" Audit Log entry. The "created" entry in the Audit Log depemds on how the record was created: if a record is created by a report or other source outside of our API, then there will be no "created" entry in the Audit Log.

Since the donation is correctly in the batch but just has the wrong date, you can go to the Donation record, click Edit, change the date, and click Save.

Yes, to omit certain payment types (like non-cash) from showing, go to the Payment Type record and set Omit Amount On Statement field to Yes. This will exclude this type of payment on all standard contribution statements.

First, do a thorough search on the Donations page to ensure that the donation is missing. Check your views, search various ways, assign the default contact to real donors, and so on. If you still can't find the Donation record, it is possible that there was an error or other issue during the transaction that prevented the record from being created in MinistryPlatform. Most errors are reported to Support automatically and passed on to you. Report missing records to Support detailing the date, time, records affected, how you discovered it, and other helpful information. Also, it's helpful to include details on what the person experienced. You can manually create the missing donation in the Platform or in the Batch Manager Tool. The best way to catch these missing donations is to regularly reconcile MinistryPlatform with Authorize.Net. Batching from Authorize.Net and eCheck Reconciliation in Authorize.Net provide insight on how to reconcile. Don't forget to reconcile your bank account to your general ledger as well!

In general, open the donation record in the Platform. Go to the Distribution tab, and click New. Then, enter the amount and the program. Click Save.

There are a few ways you can handle this:

• Reassign the donations to the living spouse.
• Leave the deceased spouse in the household and using a statement type of family.
• Include a separate statement for the deceased spouse.

One way in which to record this:

• Record the donation with two distributions records:
  • The first distribution can be the amount that was the actual donation that is tax-deductible.
  • The second distribution can be a "non-cash" donation type with a note added to the donor with the IRS language your organization uses about the non-tax-deductible portion of this donation.
• The non-cash donation amount will display as "0" on the donor statement and, depending on the note, will display on those donor statement types that display notes.

If you do not want to export these donations to the accounting system, follow the steps below. Once you have created the batch once, you may choose to use the Copy Batch Tool to reproduce this batch for every payroll:

• Create a Batch for the deductions in the Batch Manager Tool.
• Finalize the batch.
• Deposit the batch.
• Mark the batch as exported (without sending to your accounting system).

When copying a donation directly, you can copy the donation distribution tab. However, the Display Copy field is set to No by default on the donation and donation distribution tabs so that when you copy a parent page (for example, Event, Batch, Program), you don't create duplicate Donation records. Only a SPoC with full understanding of the possible consequences of mistakenly duplicating Donation records should change this value. If you actually need to copy donations, use the Copy Batch Tool or the Copy Selected Donations report.

Depending on what details were available for these batches and donations in your previous system, the out of balances might have been a necessary result of your data migration.

If needed, you could try and go back and do the research in your GL to clean up each batch. You would want to be extremely careful and extremely confident in any changes made. We strongly recommend reviewing the batches to ensure you don't lose any data and reconciling the batch and related donation totals to your GL (both before and after any edits). To do this:

1. Open the batch.
2. Jump to the deposit.
3. Find the deposit in the financial system.
4. Confirm deposit total and count match.
5. Review to confirm that adjusting the donation amount, batch total, or distribution in MinistryPlatform won't require changes in the financial system.
6. If not, manually make the change.
7. If so, manually make the change AND make a corresponding journal entry in the financial system.
8. When done, review both systems again to confirm everything is in balance.

When you cancel an event, or registrants can no longer attend, some registrants may request that their payments be considered donations. See Converting Payment into a Donation for steps to do this.