Welcome to Lesson 11.5! Setting up FastFund Raising correctly from the very beginning is crucial. The choices you make during implementation dictate how effectively you can search for donors, generate accurate financial reports, and maintain compliance. Because FastFund is deeply integrated and table-driven, mistakes made during the initial configuration can cause long-term data management headaches.
In this lesson, we will highlight the most common setup mistakes organizations make and the best practices you should follow to avoid them.
1. Chart of Accounts Pitfalls
Your Chart of Accounts format is the backbone of your system. A common mistake organizations make is rushing through this setup without proper planning.
- Permanent Definitions: Defining your chart of accounts requires identifying the account number segments (funds, cost centers, object codes) and the exact length of each segment. Crucial Rule: Once you begin to identify the individual segments to make up your chart of accounts, you cannot change the account number definition. You must plan this structure carefully, ideally in consultation with your outside accountant or fiscal team.
- Duplicate Descriptions: FastFund prevents you from creating duplicate account numbers, but it does not prevent you from using the same description for different account numbers. A common error is setting up multiple object codes with the exact same name (e.g., identifying both account 6000 and 7000 as “Rent Expense”). This creates massive confusion when posting activity and analyzing reports.
2. Inconsistent Use of Codes
Codes (such as Attributes, Classifications, and Roles) add powerful database functionality by allowing you to categorize constituents. However, failing to establish strict internal rules for coding can ruin your reporting.
- The Consistency Rule: Codes must be used consistently throughout FastFund to maintain the integrity of your database. For example, if one user sets up an Attribute code called “Newsletter” and another user sets up a Classification code called “Receives Newsletter,” your database becomes fragmented. When you try to run a query to generate your mailing list, the results will be incorrect unless you remember to include both distinctly different fields.
- Prevention: FastFund proactively helps by preventing you from entering duplicate code names across all tables (e.g., you cannot create an Industry code called “Church” and an Affiliation code also called “Church”).
3. Creating Redundant Entities
As discussed in Lesson 11.1, FastFund uses a shared entity database spanning the Accounting, Payroll, and Fundraising modules.
- The Mistake: A frequent error is manually creating a brand-new Constituent record for a donor when that individual or company already exists in the system as a Vendor or Client.
- The Solution: You should maintain one single entity record that shares contact data and assign it multiple sub-classifications. This prevents duplicate entries, ensures address updates only have to be made once, and allows you to view the entity’s complete financial relationship with your organization. Always use the “New from Existing Entity” utility when adding a constituent who might already do business with your organization.
4. Mailing Filter Errors
When it is time to extract your data for an appeal, building an improper report filter can result in wasted postage and annoyed donors.
- The Duplicate Address Error: Because FastFund allows you to store up to five different addresses for a single constituent (Primary, Work, Alternate, Billing, Shipping), generating a mailing list without a specific address filter will result in multiple output rows (and therefore multiple mailing labels) for the same person.
- The Golden Rule: When creating a filter or custom query for a physical mailing, you must always include the criteria: Address Select Is Equal to True. This ensures your query only pulls the single, preferred mailing address for each donor.