Column Glossary for General Financial Import
  • 14 Aug 2024
  • 22 Minutes to read
  • Dark
    Light
  • PDF

Column Glossary for General Financial Import

  • Dark
    Light
  • PDF

Article summary

1) Very important tips; PLEASE READ before you begin. (Click here to expand.)

  • Make sure you are using the proper import screen and have the correct import option selected: Tools → Standard Web Import; choose General Financial Import.

  • Column headers in the import file must match the EXACT names in the list below for them to be recognized by Admire.

  • The vast majority of the columns only need to be included if you have data for them. However, the system will not allow you to import financial information without at least a filled-out AMOUNT column and a filled-out PMTMETHOD column. This is true even if you are only creating a PLEDGE; you still need to fill out a PMTMETHOD for each record (although obviously it will not be recorded in such a situation and will be of no bearing).

  • Additionally, if creating PLEDGES (either on their own or along with PAYMENTS; see columns below), the system will also require you to fill out the OCCASION column.

  • Note as well that you will also need the ACTID column to be filled out before importing financial data, but you generally will NOT have the ActId column pre-filled on your spreadsheet. Instead, you will generally first match and create all the accounts on your spreadsheet before importing the financial information (the match/create process populates the ActId of each row one-by-one as you go down the list).

  • You may not include two columns with the same name... EVEN IF ONE IS BLANK.

2) How to use this document; PLEASE READ before you begin. (Click here to expand.)

  • This document serves as a glossary of column headers on Admire’s Standard Web Import screen’s General Financial Import. In this glossary you will find exact column header spellings as well as comprehensive notes containing column-specific rules, idiosyncrasies, guidelines, and tips.

  • This document does not contain instructions for importing; it is a glossary where you can find assorted information regarding the import columns.

  • Therefore, when you’re having trouble with a column, this glossary is your first line of defense.

  • However, for step-by-step importing instructions, check out our other import docs (click here).

  • The headings in this document represent the names of the columns that can be imported using the General Financial Import on the Standard Web Import screen.

  • Headings that are marked with an asterisk contain content. Click on them to expand.

  • Headings without asterisks do not yet contain content.

  • When reviewing the financial columns, it is VERY IMPORTANT to carefully take note of whether each respective column pertains to PLEDGE information or to PAYMENT information (or to ACCOUNT information).

ActId *

  • You may enter the Admire Account ID here.

  • You will probably not have the Admire Account ID right away. It will populate automatically as you match each row on the import to its proper account in Admire (or create a new account for the row).

  • If you save the spreadsheet before completing the entire import, then your new saved spreadsheet will contain the Account IDs of whichever accounts you already matched/created, so you won’t have to match/create all the accounts again.

  • If you know some or all of the Account IDs from the outset, you may certainly fill in this column on your own.

WebId *

  • If your spreadsheet includes this column, the values will get added as Global Merge Fields on the pledge and/or payment that you import (depending upon whether you import a payment or a pledge or both).

  • The Web ID can then be used for cross-checking and reference.

  • If you don't know what Global Merge Fields are, you can still leave the column on your import if you wish (if the spreadsheet you are uploading contains a Web ID). It won't pose a problem; it will simply get imported and remain available if you ever need to use it.

  • If you did the Participant Import, then note that this is NOT the column you would use to match up the Web IDs of your raisers/ambassadors/teams from that import to this one; you would use the Association column below.

Occasion *

  • Use either an Admire Occasion ID or an Admire Occasion Name.

  • The Occasion must already exist in your Admire; you need to add it before importing.

Association *

  • You can input an Association Name (you have likely seen this field interchangeably called Association Name, Association Code, Association, and Association Code Name in the system).

  • Alternatively, you can input an Admire Association ID.

  • The associations in this column must be PLEDGE associations.

  • A pledge association is a specific tag used to classify PLEDGES.

  • Of course, there are other types of associations, but associations you add in this column must be PLEDGE associations specifically.

  • You CANNOT import ACCOUNT associations on the General Financial Import straight from a column on your spreadsheet.

  • You can assign ACCOUNT associations one-by-one on the bottom left of the standard New Account screen that will display as you Match/Create accounts on your spreadsheet before processing the financial portion (of your spreadsheet).

  • If you have a default “hammered down” association in your standard New Account screen, that default ACCOUNT ASSOCIATION will indeed get automatically imported.

  • In general, you CAN import ACCOUNT associations using the Account Import utility (Tools → Data Maintenance → Import Accounts), but that uses a separate import screen.

  • To easily add many varied ACCOUNT associations from a column on your General Financial Import spreadsheet, save the final spreadsheet after matching/creating all of the accounts (this spreadsheet should show every Account ID), download to your computer, copy the spreadsheet in Excel, and delete every column except the ActId column and the columns related strictly to ASSOCIATIONS. Follow the instructions in this documentation for assistance.

  • You CANNOT import PAYMENT associations or any other types of associations.

  • Depending on your exact needs, it will likely not be difficult to assign ACCOUNT or PAYMENT, etc., associations in a streamlined manner after completing the import (especially if you proceed to do so immediately); you can use the filters on the Search Accounts screen and the Payment Maintenance screen, etc., to assist you. For more details and assistance, feel free to start an Admire Community Forum thread on the topic, or discuss with your Admire Consultant.

  • The PLEDGE associations you add in this column must match existing PLEDGE associations in your Admire database.

  • If any of the associations you input have not yet been added to your Admire, you can either select a corresponding Admire pledge association from the dropdown available in the cell (click inside the cell to access the dropdown), or create a new pledge association on the spot (just right click on the association cell to pull up that option).

    DISREGARD THE REST OF THESE POINTS IF YOU DID NOT USE THE PARTICIPANT IMPORT FOR YOUR CAMPAIGN:

  • If you used the Participant Import to create specific pledge associations for all of your raisers/ambassadors, you can input the Web IDs that match up with those associations INTO THIS ASSOCIATION COLUMN ON YOUR IMPORT... and then the system will know to link the appropriate association to each respective pledge.

  • The donation export from your campaign platform should have a column listing all the relevant IDs. Just edit that column's header to Association.

  • If you use Rayze/It and are additionally using the Rayze.It integration (i.e., if you are loading your spreadsheet ready for review/matching/importing straight from Rayze It onto your Standard Web Import screen), then this column will even be named "Association" already, so you won't even need to edit the column header to "Association."

  • NOTE: EVEN WHEN USING THE WEB IDS FROM THE PARTICIPANT IMPORT IN THE ASSOCIATION COLUMN, THE ASSOCIATION COLUMN HAS ABSOLUTELY NOTHING TO WITH THE WEB ID COLUMN MENTIONED ABOVE ON THIS PAGE. THE WEB ID COLUMN ON THIS PAGE (MENTIONED ON ITS OWN ABOVE IN THIS DOCUMENT) REFERS TO A WEB ID THAT IDENTIFIES EACH DONATION FROM YOUR CAMPAIGN. THE WEB ID DISCUSSED IN THIS PARAGRAPH REGARDING ASSOCIATIONS... DOES NOT; IT PERTAINS INSTEAD TO WEB IDS THAT IDENTIFY AND MATCH EACH RAISER/AMBASSADOR IN YOUR CAMPAIGN WITH A SPECIFIC ADMIRE PLEDGE ASSOCIATION.

Association2 *

  • Used to import a second pledge association.

  • Same rules as the previous column… EXCEPT:

  • You can only input the Participant Import Web ID in the Association column, not the Association2 column.

Title

LastName

FirstName

If you have His/Her columns (columns that indicate information specifically for the main Male and main Female names on the account), then click here to expand for the precise column names to use for those extra columns. They each begin with either the word “His” or the word “Her.”

Click here for an Admire Community Forum thread that discusses some guidelines for these extra columns.

HisName

HerName

HisTitle

HerTitle

HisInitial

HerInitial

HisInactive

HerInactive

HisOccupation

HerOccupation

MaidenName

UseMaidenName

Address

City

State

Zip

Apt

Country

Email

Phone

PhoneWork

PhoneCell

  • The import also recognizes column headers whose names match existing Admire Tel Types that can be found in the List Editor on your database (Tools → List Editor; click the plus sign next to “Editable Lists.” TelType will be the third option in the expanded section).

  • You can enter extensions in any Phone field; use this format: 1234567890 ext 123

Amount *

  • Input the FULL AMOUNT of the pledge/payment.

  • Later columns will be used to delineate the breakdown of payment plans and billing installments.

Date *

  • The date of the pledge (for recurring, this will be the date of the FIRST pledge).

  • If no date is inserted here, the system will use the date you process the import.

PaymentDate *

  • You only need to fill this out if you want the date listed on the payment to differ from the pledge date.

  • In reality, this is not only a "PAYMENT"-related field; in fact, this field will determine the date of the first installment (if you are creating a Billing/Installment Plan at this time). So, this means that the PaymentDate field determines when the first installment of the PLEDGE becomes DUE, as well as the date of the first payment in the Payment Plan (since the payment plan follows the details of the Billing/Installment Plan).

  • See below for more explanations of Billing/Installment Plans, etc.

AccountType *

  • You may enter either Personal or Business.

  • No other types will be recognized, even if you have added other types to your database in the List Editor.

Company *

Company name for BUSINESS account types.

CareOf *

There have been reports of this column not working properly. Our programming team is working on the issue, and we will update when there is a resolution.

PmtMethod *

  • You can input either an Admire Payment Method Name or an Admire Payment Method ID.

  • Payment Method ID can be found in the top right corner of the Payment Method Setup screen.

PrintReceipt *

  • Input either True or False.

  • This column indicates whether a receipt should be generated for this payment from Admire. True will indicate to the system that you DO want a receipt to be generated through Admire, and False will indicate to the system that you DO NOT want a receipt to be generated through Admire.

  • The reasons you  may not want a receipt to be generated through Admire include that perhaps the online campaign platform you used already sent receipts to everyone, or that you simply don't want receipts printed for this particular payment, etc.

  • Of course, receipts don't just get generated on their own unless you have automated your system to do that. So in reality, selecting True here merely places the particular payment's receipt into your system's receipting queue. Once the payment's receipt is in the queue, then if an automation exists, it will be generated automatically, and if no automation exists (or the payment is somehow excluded from the automation via a specification on your automation's filter), then you will find the receipt in the receipting queue on the Mail Merge Wizard when you go about manually generating receipts.

  • Note of course that even if you select True, other factors may still prevent a receipt from being generated, such as a payment date being in the future, or the payment not being applied to a pledge, etc. See here for a comprehensive listing of receipting requirements.

  • Note, as well, that if you do not include this column, the system will by default mark the column with a neutral indicator, which is equivalent here to False.

  • Also note that this column has NOTHING to do with PLEDGE INVOICE PRINTING INDICATORS. Pledge invoice printing indicators are not marked to be printed when pledges are created via an import... even if you are ONLY creating a pledge and are not creating a payment at all... UNLESS YOU CHANGE YOUR SETTINGS IN YOUR USER PREFERENCES for either your entire system or for your particular username.

  • The path to change that setting is Tools → User Options → Preferences. Then click on Web Import (not the plus sign; click on the actual words), and then -- under either User Preferences or System Preferences (depending on which you desire) -- mark Print Invoice to True/False and click Save.

  • Note that if you set pledge invoices to get marked to print, they will be marked to print even if you input False in the PrintReceipt column (as PrintReceipt ONLY affects the receipt, not the pledge invoice).

  • Generally, you'll want to leave the Print Invoice setting at False, but you are welcome to start an Admire Community Forum thread on the topic or discuss with your Admire Consultant if you suspect it would be best to mark it as True and you aren't sure.

RecPrintDate *

If a receipt was already sent for the payment (NOT using Admire), this field can be used to record the “Receipt Print Date” of that receipt.

PmtSendVia *

  • This sets the method to be used to send receipts (Mail or Email).

  • This does not mean that the receipt can ONLY be sent via the method chosen. It is used for filtering and also to allow specific non "account default" physical/email addresses to be chosen for a particular payment.

  • Note, however, that while you may indeed wish to fill in this column for filtering purposes, it doesn't really matter here for the purpose of choosing non-default addresses, since you anyways can't select such addresses on the import (because the addresses on the import apply only to the account as a whole, and even if you add a non-default address on the import, it won't be set for the particular payment, only for the account in general), and once you go into the payment's screen manually to select the non-default address, you'll be able to simply change from Mail to Email (or vice versa) on the spot.

LetterCode *

  • Input the name of an existing receipt template from your Admire database.

  • This column pertains ONLY to PAYMENT RECEIPTS, not to PLEDGE INVOICES.

Notes

This is for Payment Notes.

PledgeNotes

CheckNumber *

Cannot include non-numeric characters.

CheckDate

Batch *

Admire Batch Id or Admire Batch Name.

PlgStartDate *

Generally not used.

PlgEndDate *

Generally not used.

ForeignAmt

ExchangeRate

TaxDedAmt

CumulativeRec *

Enter either True or False.

ReceiptNumber *

Cannot include non-numeric characters.

PlgOnly *

  • Enter either True or False.

  • If True, no payment will be created... only a pledge will be created.

  • If this column is not included in your spreadsheet, the system will nevertheless load the column with NEUTRAL (for all intents and purposes: UN CHECKED) checkboxes down the line.

CreatePlg *

  • Enter either True or False.

  • If False, ONLY a payment will be created.

  • If the column is not included, the system will nevertheless load the column with CHECKED checkboxes down the line.

  • Whether the column was or was not included on the original spreadsheet, once the spreadsheet loads onto the import screen with the column, you must ensure that all the cells in the column contain one of the following: a checkbox (that is neutral/checked/unchecked), the word true, or the word false... and nothing else.

  • If you start getting errors complaining about such delights as "dbnull" and "boolean" and other such unintelligible misdemeanors, this column is one of the first ones you should check for issues, i.e., check if any cell in the column contains something other than a checkbox (that is neutral/checked/unchecked), the word true, or the word false.

PlgId *

  • When importing donations, you have the ability to import each row on your spreadsheet as a pledge and payment together, as a pledge alone, or as a payment alone.

  • If you decide to import ONLY a payment for a particular row, you can:

    • Leave the payment unapplied.

    • Apply it to an existing pledge in your system by inserting an existing Admire Pledge ID into THIS PlgId column.

  • There are several ways to insert that existing Pledge ID. You can:

    • Select one of the account’s outstanding pledges from the bottom right of the import screen.

    • Set the import screen to prompt you to choose an existing outstanding pledge for each row as you process the import row-by-row.

      • The prompt does not lock you in. If you prompt, you will have the option to skip and not select an existing pledge in the pop-up for each row... and instead keep the payment it imports as unapplied -- or use pledge information on the spreadsheet to create a pledge if you checked off CreatePlg.

  • Regardless of how you choose the pledge, the pledge’s PLEDGE ID will get filled into the PlgId column once it is chosen (when prompting, the fact that the column is filled with the ID is only relevant if you are saving the spreadsheet for your records, because the payment is imported instantly anyway… as soon as you choose the pledge in the prompt pop-up).

  • Note that you can ALSO simply type in a PlgId yourself (if you know the correct PlgId). That works as well.

  • Note that payments on the import are only meant to be applied to pledges with outstanding amounts either equal to or greater than the payment amount. They are not meant to be applied to pledges with outstanding amounts lower than the payment amount. By the same token, you cannot use an import to instantly apply one payment to multiple pledges.

    • Note: If you are filling in the PlgId column by clicking on the desired pledge in the bottom right corner of the screen or by choosing the pledge after being prompted, and the payment amount exceeds the pledge’s outstanding amount, the system will actually only allow you to choose the pledge if you agree to raise the pledge amount to the point where the pledge’s outstanding amount is equal to the payment amount.

    • If, however, you fill in the Pledge ID numbers manually, the system will simply accept what you inputted. Yet the system will not just leave the excess amount of the payment as “unapplied.” Instead, the entire amount of the payment will be applied to the pledge in question, even though that amount exceeds the pledge’s outstanding amount! In fact, once you import, you’ll see that the pledge whose ID you inputted will have Outstanding (and Due Now) amounts in the negative. THIS CAN OBVIOUSLY POSE AN ISSUE (both for your general records and for statements, etc.), SO PLEASE BE FOREWARNED.

    • Throughout the rest of the Admire program, you can certainly apply payments to pledges that have outstanding amounts lower than the payment amount. The system would simply apply up to the correct amount and then leave the rest of the payment unapplied (you can also apply to more than one pledge, of course, so that the whole amount of the payment is applied… but again, not on the import, as stated above).

      Two final points regarding this PLGID column FOR ADVANCED ADMIRE USERS:

        • Generally, you can only create Payment Plans based off of Billing/Installment Plans. Therefore, when importing a pledge/payment together, it makes sense that if you enter installment information (which technically applies to the pledge) it would also create a payment plan. Yet, one may have thought that if a payment being imported was being applied to an already existing pledge, then it would not be possible to create a payment plan.

        • In truth, however, even when you apply the payment you are importing to an existing pledge, you can still create a payment plan on the import if you fill out installment information (see columns listed below in this document).

        • In fact, you will be able to create a PAYMENT PLAN even if the Pledge has its own Billing/Installment Plan! (And the Billing/Installment Plan of the pledge itself will NOT be affected!)

        • On a different note, but very powerfully: It was mentioned just above that you can use this PlgId column to apply payments you are importing to existing pledges. In fact, this PlgId column can apply payments to existing pledges even when the existing pledge belongs to an account other than the payer account!

        • In other words, you can use the import to have one account pay off a different account's pledges!

        • What you would do is this: Match/Create the payer's account or simply insert their existing Admire Account ID if you already know it, and then, in the PlgId column, simply insert the ID of the pledge to which you want to apply the payment (the ID of the pledge you want the payment to pay off), just like you could do if the pledge was from the payer's account!

        • You could even set up a payment plan by filling out installment information... just like you could do if you were applying the payment to an existing pledge on the payer's own account.

Here are a few notes about RECURRING DONATIONS in Admire (click here to expand).

  • RECURRING DONATIONS IN ADMIRE (WHETHER IMPORTED OR CREATED IN ANY OTHER WAY) NEVER SIMPLY GET CREATED ON THEIR OWN. You create them via the Create Recurring Donations update on the Report Wizard (fill in the Run Update bubble first in Section 1), or via an Advisor automation that runs the update for you on its own.

  • If you have an Advisor automation set up for your organization, it may indeed seem that the recurring donations are automatically created -- and that's great, because they ARE being created automatically, for all intents and purposes -- but if you ever need to troubleshoot an issue with recurring donation creation, it's integral to know this background information.

  • Whether you run an automation or manually process the update, the donations created are the ones eligible for creation based on their interval types and the fact that they are marked as recurring.

Recurring *

  • Enter either True or False.

  • True means that the pledge should recur. False means that the pledge should NOT recur.

IntervalType *

  • This field is mentioned AGAIN below regarding installments, as well.

  • IT IS ONLY ONE COLUMN, AND YOU SHOULD ONLY HAVE IT ONCE ON YOUR IMPORT, BUT IT WILL ACT DIFFERENTLY FOR EACH ROW DEPENDING UPON WHETHER THE ROW REPRESENTS A RECURRING DONATIONS OR A NON-RECURRING DONATION WITH INSTALLMENTS.

  • Here's how it works for RECURRING DONATIONS: The interval type determines how often the recurring donation will have a new pledge/payment become ELIGIBLE FOR CREATION (see below).

  • So, you can input any of the available Recurring Donation interval types (the types available on the setup screen for Recurring Donations), i.e., Weekly/Monthly/etc.

  • The default is Monthly.

RecurringEndDate *

This column is only relevant to recurring donations.

For donations NOT paid in full -- the next five columns below determine both the Billing/Installment Plan (the Billing/Installment Plan determines when each portion of the pledge becomes DUE), as well as the Payment Plan (the post-dated  payments that Admire will create based precisely off of the amounts and dates of the installment plan). If you are not creating a pledge for this row of the import (i.e., the row's PlgOnly/CreatePlg are both marked False), the system will still use the columns below to simply create scheduled postdated payments in a Payment Plan... even though you are obviously not creating true installments (since, in reality in Admire, installments are PURELY a PLEDGE-RELATED term, and you are not creating a pledge at all).

InsQty *

  • Number of installments to create for this pledge.

  • THIS PERTAINS TO INSTALLMENT/BILLING PLANS, NOT TO RECURRING DONATIONS.

IntervalType *

  • This field was already mentioned above regarding Recurring Donations, as well.

  • IT IS ONLY ONE COLUMN, AND YOU SHOULD ONLY HAVE IT ONCE ON YOUR IMPORT, BUT IT WILL ACT DIFFERENTLY FOR EACH ROW DEPENDING UPON WHETHER THE ROW REPRESENTS A RECURRING DONATIONS OR A NON-RECURRING DONATION WITH INSTALLMENTS.

  • Here's how it works for NON-RECURRING DONATIONS WITH INSTALLMENTS: The interval type determines whether the system will create pledge installments separated by a specified number of WEEKS, or instead, separated by a specified number of MONTHS. So, you can input either Weekly or Monthly.

  • The default is Monthly.

  • In the next column, "Interval," you will specify the actual NUMBER of weeks/months that the installments will be separated by (i.e., if you choose WEEKS in this IntervalType column, then the next column, "Interval," will refer to a number of WEEKS, and if you choose MONTHS in this IntervalType column, then the next column, "Interval," will refer to a number of MONTHS).

Interval *

  • See above paragraph for explanation.

  • THE "INTERVAL" COLUMN PERTAINS TO INSTALLMENT/BILLING PLANS, NOT TO RECURRING DONATIONS.

  • This Interval field would, of course, be a number. For example:

    • 1: either every week or every month, depending on the IntervalType chosen 

    • 2: either every two weeks or every two months, depending on the IntervalType chosen 

    • 3: either every three weeks or every three months (quarterly), depending on the IntervalType chosen 

    • 7: either every seven weeks or every seven months, depending on the IntervalType chosen 

    • 12:  either every 12 weeks or every 12 months (yearly), depending on the IntervalType chosen  


      The default is 1 (once a week/month).

InsAmount *

  • Specific installment amount (the website you are importing from may calculate how to split up the pledge differently than Admire does).

  • The amount you choose here is the amount that will be set for every installment (except the last one, if the math doesn't work out evenly).

  • You cannot set specific installment amounts for random installments on the import (you CAN do so in Admire proper).

  • THIS INSAMOUNT FIELD PERTAINS TO INSTALLMENT/BILLING PLANS, NOT TO RECURRING DONATIONS.

InsLastAmount *

Specific amount for the LAST installment to pass in (if it is different than the InsAmount). THIS PERTAINS TO INSTALLMENT/BILLING PLANS, NOT TO RECURRING DONATIONS. 

Credit Card information:

CreditCard   *

Credit card number.

ExpDate *

 T he left two characters are the Expiration Month (02 for February), and the right 2 characters are the Expiration Year.  Acceptable formats:  02/12, 02/2012, 10-10, 10-2010

AlreadyBilled *

  • Enter either True or False.

  • Should be set as True if the credit card was billed through the website, and False if the credit card should be billed through Admire. If you are setting up payment plans (see above), and you set AlreadyBilled to True, the system will know to only mark the FIRST payment as true.

CCResult

TransactionResult

Token

SecureStorageMethod *

Method used to store the credit card in Admire.

ProcessingFeeAmt *

  • Add the amount of processing fee (Actual fee amount = Pledge Dollar Amount x the Processing Fee %).  The system will create a separate pledge towards whatever your processing fee occasion is and will add the fee to the payment total.

  • This column is available for Admire Unlimited Azure clients only.


Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.
ESC

Eddy AI, facilitating knowledge discovery through conversational intelligence