Campaign Finance and PAC Compliance Software: Catching the Breach at Deposit, Not at Filing

Why the breach happens at deposit and gets discovered at filing

A $2,000 check arrives at a connected PAC in the third week of the cycle. The donor gave earlier in the year through an online conduit under a slightly different name spelling, and gave again to an affiliated state committee that shares the federal limit. Individually, none of those looked like anything. Together they crossed a line six weeks ago.

Nobody knows this yet. The check gets deposited because deposit is a bank operation and the compliance review is a batch process that runs when the report is assembled. The discovery comes at pre filing review, when an aggregation query finds four donors over the line, two of them now outside the window in which a refund, redesignation or reattribution cleanly cures it. Now it is a disclosure, a correspondence file, and a conversation with counsel. The treasurer signs personally, which is the part people outside this world do not understand: the exposure is not abstract.

Problem 1: the limit is an aggregate, and the aggregate crosses boundaries

A federal contribution limit is not a per check number. It is per donor, per election, per cycle, with the primary and the general counting as separate elections, indexed for inflation between cycles. A general election contribution accepted before the primary is contingent on the candidate reaching the general. Affiliated committees share a single limit, which means a donor's gift to one entity consumes capacity at another. Joint fundraising committees allocate proceeds across participants according to a formula, and each allocated slice lands against its own limit.

Now add identity. The same human being appears as Robert, Bob, Robert J., at a home address on one gift and a business address on another, and through a conduit platform with whatever formatting that platform passed through. Aggregation is only as good as identity resolution, and identity resolution is the hard computer science problem hiding under what looks like a bookkeeping task.

NGP and Aristotle both do this competently for the mainstream case, and this article is not going to pretend otherwise. Where committees outgrow them is structural: an organisation running a federal PAC plus a super PAC plus a 527 plus state committees in eleven states needs aggregation across an entity graph designed for its own affiliation rules. Packaged products model the common structures. If yours is unusual, you will maintain the unusual part in a spreadsheet, which is the thing you were trying to stop doing.

What a custom build does: aggregation runs at intake, synchronously, before the deposit batch is prepared. Identity resolution scores candidate matches and puts anything ambiguous into a human review queue rather than guessing. The entity graph of affiliation is explicit data, not code, so when your organisation adds a committee the compliance team configures it instead of filing a change request. And every receipt carries a live remaining capacity figure for that donor, so the finance director asking whether a donor can give again gets an answer in seconds.

Problem 2: employer and occupation, and the standard you are actually held to

Individual contributions aggregating above $200 in a cycle must be itemised with the contributor's name, address, occupation and employer. Committees are held to a best efforts standard for obtaining that information, and best efforts is a documented process, not an intention. If you cannot show the follow up requests you made, you did not make best efforts.

The operational reality is that events produce the worst data. A check handed over at a reception with a scrawled note. A ticket bought online where the donor typed retired, or self, or their spouse's employer, or nothing. A conduit contribution that arrives with fields your platform did not require. Then someone has to chase it, and the chase has to be evidenced.

What a custom build does: treat missing itemisation data as a tracked obligation with a state machine. Identified, requested, requested again, received or documented as unobtainable, with the actual outbound message stored. Automate the follow up sequence so it happens on schedule rather than when someone remembers. This is also the one place in the category where a language model does honest work: normalising the free text employer and occupation people type, mapping self employed variants, catching an employer name that matches a federal contractor list, and flagging entries that are almost certainly incomplete rather than genuinely absent. It suggests, a human confirms, and the confirmation is logged.

Problem 3: prohibited sources are a screening problem, not a checkbox

Corporate treasury funds, national banks, federal contractors and foreign nationals cannot give to federal committees. Nobody sends a check labelled foreign national. What arrives is a personal check from someone with a foreign address, or a contribution from an LLC whose ownership determines whether it is permissible and whose ownership is not on the check, or a gift from an individual who works for a company that happens to hold federal contracts, which matters for some committee types and not others.

The screening has to happen at receipt because the cure is a refund, and refunds have windows. What a custom build does: run every receipt against configurable screening rules at intake. Address country checks, LLC and partnership flags that force an attribution question before acceptance, entity name matching against contractor sources you designate, and a hold state that lets a committee bank a check while flagging it as unconfirmed rather than accepting it. That hold state sounds small and is the feature compliance directors ask about first, because the alternative is either refusing money you might legally keep or accepting money you might not.

Problem 4: fifty one rulebooks, and every one of them files differently

Federal reporting means Form 3X for a PAC or Form 3 for a candidate committee, with Schedule A for receipts, Schedule B for disbursements, Schedule C for loans, Schedule E for independent expenditures, and 24 or 48 hour notices with their own triggers near an election. That is a known and stable target, and the FEC publishes its format.

States are the real problem. Every state sets its own limits, its own itemisation thresholds, its own reporting calendar and its own electronic filing schema. California's system and Texas's system share nothing in common. Some states still want a signed paper form. Limits change between cycles in some jurisdictions and after ballot measures in others. A committee active in a dozen states is maintaining a dozen rule sets, and the person who knows them is one person.

What a custom build does: make jurisdictional rules configuration data with effective dates, never code. A limit is a record with a jurisdiction, an entity type, a donor type, an election, an amount and a date range. When a state changes its limit, compliance edits a record, and every historical determination still reproduces under the rule that applied at the time, which is what you need when a state regulator asks about a contribution from two cycles ago. Filing output gets built as a set of format adapters over one internal model, so adding the thirteenth state is a week of work rather than a new project.

Problem 5: corporate and association PACs have a whole second operating problem

If you run a connected PAC at a corporation or trade association, none of the above is your hardest day. Your hardest day is payroll deduction. Employees authorise a deduction amount, payroll runs, a file comes back, and every one of those small amounts is a contribution with a date and a limit implication. Deductions change mid year. Employees leave. The corporation must have authorisation to solicit its restricted class, and solicitations of anyone outside it are a separate problem entirely. Trade association PACs need prior approval from member companies before soliciting their executives, and that approval is annual and per company.

What a custom build does: hold the authorisation, the deduction schedule and the payroll file reconciliation in one place, with member company prior approval tracked as a dated permission that gates solicitation lists. Then generate the semiannual lobbying disclosure contribution data from the same ledger, instead of the government affairs team rebuilding it by hand twice a year. Associations we have worked with recover a week of senior staff time per filing period on that alone.

What this costs and how long it takes

A first release covering contribution intake with synchronous aggregation, identity resolution, limit and prohibited source screening, itemisation data chasing, and federal Form 3X or Form 3 output with the core schedules runs $70,000 to $150,000 and ships in 14 to 20 weeks. This category runs longer than most at the same price because the rules work has to be done properly and reviewed by someone qualified, and that review is not optional.

A full platform adding multi state filing adapters, affiliated and joint fundraising committee allocation, refund, redesignation and reattribution workflow with window tracking, payroll deduction for a connected PAC, and disbursement side compliance runs $180,000 to $450,000 phased over 8 to 14 months.

What drives it up: the number of state jurisdictions, at real weeks each. Conduit and platform integrations, since each one passes different fields. Independent expenditure reporting, which carries its own timing triggers and its own risk. Historical data migration, because importing five cycles of contributions into a system that aggregates means confronting every identity ambiguity in your existing data at once, and that is a project in itself. And the requirement, which we insist on, that a compliance attorney or experienced treasurer reviews the rule configuration before launch. Budget for their time.

Build versus buy, and when buying is the right call

Buy. That is the default answer in this category and we will say it plainly even though we build software for a living. NGP and Aristotle carry years of accumulated rule knowledge, they update when regulations change, and a single federal committee raising under a few million dollars a cycle will be better served and better protected by buying one of them and hiring a good compliance consultant. Building a limit engine from scratch to save subscription cost is a bad trade against treasurer liability.

Build when the structure is the problem rather than the features. Specifically, when you run five or more affiliated entities whose shared limits the packaged products do not model the way your counsel describes them. When you are active in eight or more states and already maintain the state rules in a spreadsheet outside your compliance system. When you are a corporate or association PAC whose payroll deduction, restricted class and member prior approval workflow lives entirely outside the tool. When your fundraising operation has volume that makes synchronous screening at intake worth engineering. Or when you need contribution data to feed lobbying disclosure and grassroots reporting that no campaign finance product covers.

How to choose a developer for campaign finance compliance software

Ask them where the rules live. If the answer involves writing code for each limit, walk away. Limits, thresholds and calendars must be dated configuration data that reproduces historical determinations exactly, because regulators ask about the past and your defence is showing what the rule was when you applied it.

Ask how they handle identity resolution across name and address variations and conduit platform records. If they say they will match on name, they have not thought about the problem that causes most aggregation failures. The right answer involves scoring, a review queue and a documented merge history that can be unwound.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire any other firm. At Digital Heroes the client owns the code from the first commit. A committee whose compliance system sits inside a vendor's account has a single point of failure fourteen days before a filing deadline, and there is no version of that story that ends well.