Guides & Resources › Software Guide

How automated union dues billing works, and how to know when your local is ready for it

A practical guide to what automated dues billing actually does for a union, why manual processing keeps producing wrong answers, and how to evaluate any system against five readiness stages.

We are an eMembership publication and naturally know our own platform best. This guide is written to be useful to any union leader evaluating union dues management software, regardless of which vendor they choose. It draws on how dues processing actually works inside a union, vendor documentation, and what union finance staff describe about the work.

Key Takeaways
  • The delinquent member is usually not the problem. The most common reason a member shows as unpaid is that the employer failed to remit, or remitted late and sent a correcting double deduction. A system that assumes member fault chases the wrong people.
  • Automation earns its keep at the reconciliation stage, not invoicing. Generating invoices is the easy part. The expensive, error-prone work is matching payments to members and catching the gap between what a contract says should have arrived and what actually did.
  • Accounting integration is a distinct capability from dues collection. Getting the money split, bucketed, and handed to accounting without a second system is where purpose-built and adapted platforms differ.
  • Readiness is not an "all-or-nothing". A local can automate intake while still closing the books by hand, or automate the close while a handful of self-payers stay manual. Automate the stage that hurts most first.
  • The most expensive mistake is automating intake and leaving reconciliation to be manually updated. It feels like progress because the visible keying disappears, but the errors that cost money live one stage later, at reconciliation.

What automated dues billing actually does

At its core, automated union dues billing replaces a monthly cycle of spreadsheets, manual keying, and after-the-fact error hunts with a process the system runs the same way every period.

A union dues management software platform assesses dues based on the rates in each contract, generates and delivers invoices, imports payments from banks, lockboxes, employer remittance files, and online payments, and reconciles all of it against the member ledger. When an employer underpays, skips a member, or misses a contracted rate increase, the system surfaces the discrepancy as an exception instead of letting it vanish into a reconciled total. At month end, it produces a close that can be reviewed in draft before anything is finalized, then exports the financial result to accounting.

A dues system that only records what came in has automated the easy half. The value is in catching what should have come in but did not.

The value is not speed alone, though the time savings are real. A well-built union dues collection system removes whole categories of error from the process rather than performing the same error-prone steps faster. The good systems do four jobs well:

  • They assess from the contract. Rates, effective dates, and stepped increases live in the system and apply themselves on the right date, so an employer cannot quietly keep paying last year's rate unnoticed.
  • They reconcile against expectation. The system compares each remittance against what the contract says should have arrived and flags the gaps as exceptions to resolve.
  • They close cleanly. Month-end close runs as a reviewable draft, and separate period, posted, and close dates keep a late employer payment in the period it belongs to.
  • They hand off to accounting. Reconciled dues split into their funds, disburse per-capita to the levels of the union that are owed it, and export with general-ledger mapping.

Why manual dues processing fails structurally

Manual dues processing does not fail because union staff are careless. It fails because the process asks people to do, by hand and every month, the two things humans are worst at: high-volume data matching, and cross-referencing one dataset against another to find what is missing.

Consider what a dues administrator at a mid-sized local actually does each cycle. An employer sends a remittance file, sometimes clean, oftentimes not. Names are spelled differently than they are in the membership database. An employee number has a transposed digit. One employer sends a fixed-width file from a payroll system that has not been updated in twenty years. The administrator keys or imports each row, matches it to a member, and books the payment. Multiply that across dozens to hundreds of employers.

Then comes the part that manual processing handles the worst. Somewhere in that file, an employer paid for 118 members when the roster says 122. A contracted rate increase took effect on January 1 and one employer is still remitting at last year's rate. A member who retired in November is still being deducted. These situations do not always announce themselves, and absences and discrepancies are not always caught. Finding them means comparing what you received against what you expected, line by line, which almost no one has time to do thoroughly every month.

The errors that cost a union money are not the payments that arrive. They are the ones that get missed. Manual processing does not always catch what is not there.

Unions describe the result the same way, in almost the same words: things slip past us. We have heard from unions still validating dues by taking whatever the employer sends, because they have no independent figure to check it against. We have also heard from unions running two separate reports every month just to catch corrections before the numbers go to the international level. The technology is frequently decades old: a homegrown system past its twentieth birthday, a dues platform built in-house in the 1990s, a finance operation running on a database tool never meant for it. The common thread is not bad software. It is just that the work is structurally mismatched to being done by hand, and the tools meant to help stopped being maintained years ago.

That is the case for automation, stated precisely so the fix can be precise: the goal is not to process remittances faster. It is to make the missing member and the stale rate impossible to miss.

The real pain points of manual dues billing, in plain terms

If you talk to union finance staff, a consistent set of problems comes up. They are worth naming, because the right union dues management software is defined by which of these it actually solves.

  • Employer-caused delinquency. A member shows as unpaid because their employer failed to remit, not because the member chose not to pay. Chase the member with inaccurate information and you have damaged trust while not solving anything. This is the discrepancy that union dues software exists to catch, by comparing what each employer should have remitted against what actually arrived before it becomes an arrears conversation with a member who did nothing wrong.
  • Silent underpayment. An employer remits for fewer members than the roster shows, or at the old rate, and does not come to light until later, if at all.
  • Manual keying and its typos. When the intake is transcription, every transposed digit and misspelled name becomes a mismatched record that someone has to hunt down and fix at a later date.
  • Corrections that cascade. In a system that carries balances forward, fixing a back-month error ripples into every period after it, so staff lose hours to corrections that should have taken minutes.
  • The month-end scramble. Without a reviewable draft close, staff either close blind or re-run the whole cycle by hand to check it before it goes to the international level.
  • The handoff to accounting. Dues get collected, and then a second, separate system splits and disburses the money, with re-keying in between and a fresh chance for error at every step.

Almost every manual dues problem is similar: human errors occur because the facts needed to do the job right are in a different place.

A useful test: if you cannot answer "did every employer pay for every member they should have this month at the right rate" without a manual investigation, the process is too disjointed, and automation is worth evaluating.

The Dues Automation Readiness Model: a buyer's framework

Most automation advice treats the decision as a switch: you are manual, or you are automated. That framing is wrong, and it stalls unions who look at a full platform migration and decide it is too big to start. Dues automation is a sequence of independent stages, and a local can be automated at one stage while fully manual at the next. Knowing which stage is costing you the most money tells you where to start.

The Dues Automation Readiness Model organizes the decision into five stages, ordered by how they build on one another. Locate your union at the stage where the manual pain is currently sharpest and that is your starting point.

The point of a readiness model is permission to automate out of order. Instead of fixing the first step in a workflow diagram, target the stage that causes the most pain or delay.

Stage 1: Assessment

Are dues rates and increases applied automatically from the contract, or does someone update rates by hand when a contract changes? A union stuck here is exposed to the missed-increase error: an employer keeps remitting at the old rate and no one notices for months.

Readiness signal: rates, effective dates, and stepped increases live in the system and apply themselves on the right date.

Stage 2: Intake

Can payments enter the system directly from banks, lockboxes, employer remittance files, and online payments, or is intake mostly manual keying? A union stuck here wastes staff time on transcription and inherits every typo.

Readiness signal: import templates that map each remittance format once and remember a renamed member from one import to the next, so the same manual correction is not made every month.

Stage 3: Reconciliation

True automation adds a vital check step. It compares what arrived against the contract and highlights the missing items. Automating data entry without also automating this review just helps you make errors faster.

Readiness signal: an expected-versus-received exceptions report that catches underpayment, skipped members, and missed increases without a human hunting for them.

Stage 4: Close

Can the month-end close run as a reviewable draft before it is finalized, with period date, posted date, and close date tracked separately so a late employer payment lands in the correct period? A union stuck here either closes blind or reruns the whole cycle manually to check it.

Readiness signal: a draft close that staff review and approve, and a period model that handles late arrivals without corrupting a closed month.

Stage 5: Disbursement and accounting

Once dues are collected and reconciled, can the system route dues into their respective categories, disburse per-capita to the levels of your union that are owed it, and export to accounting without a separate payout system? This is the newest stage most unions reach, and increasingly the one that decides a purchase.

Readiness signal: configurable buckets, per-capita splits at the levels your structure requires, and a clean export with general-ledger mapping.

The model is diagnostic, not prescriptive. A local strong at intake and weak at reconciliation should not be sold a close-and-disbursement overhaul first. Find the stage where the manual work produces wrong answers today, and automate there.

How automated billing actually works

With the readiness stages as the map, here is what the machinery does at each one.

Intake. Payments come in through whatever channel the employer or member uses: a deposit batch imported straight from the bank, a lockbox check feed, a check scanner, a recurring-payment import, an online payment, an employer portal where the employer uploads its own remittance file while your team keeps the reconciliation, or, when an employer sends no file at all, manual grid entry that rolls over from the prior month so staff edit a populated grid rather than start from a blank one. Import templates map each employer's format once. When a payroll company spells a work site or a member's name its own way, the system can remember the correction and apply it automatically on the next import, which is the single feature union finance staff react to most when they see it.

Reconciliation and audit. Imported payments auto-allocate against open charges, with manual override available for any individual payment. The expected-versus-received exceptions report compares the remittance against the contract and rates, so underpayments, overpayments, and missing members surface as exceptions to resolve rather than discrepancies to discover later. Two design details matter here. Balances are recomputed rather than carried forward, so correcting a back-month error does not cascade into every subsequent period. And every payment carries a payroll or period date, so an employer catch-up payment or a correcting double deduction posts to the specific back month it covers instead of landing in the current one, which keeps a member from being flagged for a gap that was already made whole. Every change is logged with the user, the timestamp, and the old and new values. That audit trail is not just good hygiene; unions are required to retain dues collection receipts, employer checkoff statements, and per-capita records under federal recordkeeping rules, and a logged history makes producing them straightforward.

Member record effects. Payment can flip a member's status automatically, including reactivating a lapsed member on payment. Life events end-date the old record and open a new one, with rate back-outs handled automatically at retirement and a deceased member's back-out leaving a credit available for refund. The pattern to notice: the automation that helps a member runs on its own, while actions that work against a member are handled deliberately rather than automatically. More on why that choice matters below.

Close. Month-end close and assessment can run as a draft for review before anything is finalized. Because the system tracks period date, posted date, and monthly-close date separately, a payment that arrives late from a slow employer lands in the period it belongs to instead of distorting the current one. The outstanding-balances report exports to CSV in one click for a delinquency mail merge, and late-fee and lapse controls are applied as policy rather than chased by hand.

None of this is exotic. It is what a union dues collection system built for the job does as a matter of course. It is worth spelling out because "automated billing" on a feature list usually means the first two stages, and the errors that actually cost unions money live at stage three and beyond.

Union accounting integration: the part most guides skip

Collecting dues is only half of a union's financial cycle. The other half is what happens to the money afterward: splitting it into the correct funds, disbursing per-capita to the levels of the union that are owed it, bundling the result into a monthly report, and handing it to accounting. This is union accounting integration, and it is the stage where a general dues page stops being helpful, and where, increasingly, the buying decision is actually made.

The need is concrete. A union with multiple levels of structure needs to apply dues, then disburse funds across those levels, then produce a monthly transmittal that accounting can use directly. The goal we hear most often is to retire the separate payout system entirely, so that whatever the dues platform produces flows straight into the books with no re-keying in between.

The test for accounting integration is not whether a vendor says yes. It is whether they can show per-capita splitting across your actual union structure without a second system. Ask for the demo, not the answer.

Union accounting integration software handles this by treating funds and disbursement as native concepts. Dues can be separated into buckets such as general income, a strike fund, disaster relief, agency fees, and political or COPE contributions. Per-capita can be flat or a percentage, configured at the lodge, contract, employer, or individual member level, with split dues calculated and distributed automatically. The financial result exports as a configurable CSV or Excel file with general-ledger mapping, scoped to your chart of accounts during implementation. On union accounting system integration specifically, eMembership has integrated with Great Plains, Sage, and QuickBooks; the right target format for any given union is confirmed in discovery rather than assumed.

An honest word on difficulty, because a guide that says this is simple is lying to anyone who has done it. Splitting dues across district and international levels is genuinely complex. But it lives in your union's constitution, not in the software. The job of a union financial management software platform is to encode that structure once, during implementation, so it runs automatically every month after. The complexity does not disappear. It just stops being monthly manual labor.

This is also where purpose-built and adapted platforms diverge most visibly. Association management systems adapted for union use, such as Aptify and iMIS, can be configured to handle dues. What are not native concepts in an association schema are funds, per-capita, and lodge-or-district-or-international disbursement. They become custom fields and custom logic is bolted on. In a platform built for unions, these are first-class structures. It is a fair distinction to raise in any of your evaluations: ask a vendor to show you per-capita disbursement to three levels of your structure, live, rather than describe it.

Scaling dues for large and multi-local unions

Everything above gets harder as a union grows, and union structures get complex in specific, recurring ways. Cloud-based union dues processing is what makes these patterns manageable, because it keeps one live dataset instead of reconciling copies across offices.

A few of the patterns that separate a large-union billing problem from a small one:

  • Multiple dues types on a single member. A retail and food-processing local might carry a flat rate plus hourly field dues plus a strike fund plus an education fund plus a political contribution, three or four dues types on one member, with some members working for several employers at once.
  • Hybrid checkoff and cash. A weekly employer checkoff applied monthly, running alongside members who pay cash, in the same period, in the same system.
  • Merged organizations that bill on different rules. When two unions merge, they often arrive with different billing cycles and different lapse rules that now have to coexist in one platform.
  • Parallel organizational dimensions. A public-sector union may run groups and subgroups against regions and branches against employers and departments against classifications, all at once, with dozens of groups each under its own agreement.
  • The long tail. A local that is almost entirely employer checkoff still has a handful of out-of-work self-payers and retirees paying a small minimum out of a pension. Those exceptions consume a disproportionate amount of time.

Cloud-native is not a buzzword for a multi-local union. It is the difference between one live dataset every office reads and writes, and four exported snapshots that are out of date the moment they are created.

The reason cloud-native matters here is because a multi-local union running one live database does not reconcile the state of the world across four regional offices every month. Every office, and every level of the union, works from the same current data. For a large union evaluating platforms for organizing their union member data and dues together, the practical meaning of cloud-native is that it is one source of truth every local reads and writes in real time.

What most unions get wrong

The most common and most expensive mistake is automating intake while leaving the reconciliation manual. It feels like progress, because the visible, tedious keying goes away. But the errors that actually cost money, the underpayments and missed rate increases and the members an employer quietly dropped, live at reconciliation. A union that automates stage two and skips stage three has bought faster data entry and kept every one of its expensive errors. When you evaluate a platform, the question that matters is not "can it import our remittances." It is "can it tell me what should have arrived and did not."

Automating intake without reconciliation makes your errors arrive faster, not less often. The stage that catches the missing member is the stage worth paying for.

There is a second, quieter mistake, and it is a design question every union should put to a vendor directly. If you automate dues, will the system start punishing members by mistake? A payment that fails to post cleanly should not silently lapse a member's standing. The principle worth insisting on is that automation runs freely in the member's favor, reactivation on payment, credits on overpayment, and rate back-outs at retirement. Any action that works against a member, a suspension or a lapse, requires a human being to make the call. That is a deliberate design choice, not a technical limitation, and it directly answers the anxiety underneath the whole category. It is worth asking any vendor whether their automation is built that way, because not all of it is.

How eMembership approaches automated dues billing

This section is about our own platform. Everything above applies regardless of which vendor a union chooses.

eMembership is a union database platform built specifically for labor unions, in continuous development for more than 20 years, currently serving 55+ union clients across 18 configurable modules. Dues and finance are core modules rather than a bolt-on, which is what lets assessment, invoicing, payment intake, expected-versus-received reconciliation, a reviewable draft close, and disbursement with general-ledger-mapped export work as native capabilities instead of adaptations of an association product.

Measured against the readiness stages in this guide, the platform is built around the same sequence. On assessment, dues rates are set at the contract level by classification or craft, with stepped schedules that update automatically on the right date. On intake, payments enter through bank deposit batches, lockbox, check scanning, recurring imports, online payment, an employer remittance portal, or manual grid entry, and import templates remember a renamed member from one file to the next. On reconciliation, the expected-versus-received exceptions report compares each remittance against the contract, and recomputed balances keep a back-month correction from cascading. On close, month-end runs as a reviewable draft with period, posted, and close dates tracked separately. On disbursement, dues split into configurable funds and per-capita disburses to the levels a union's structure requires, exporting to Great Plains, Sage, or QuickBooks with general-ledger mapping confirmed in discovery.

Pricing is a flat annual subscription with unlimited staff seats and no per-seat fees, configured to the modules a union needs through a paid Discovery Process. The Member Web Portal and Member Mobile App, which let members pay dues and check standing themselves, are add-ons rather than part of the base subscription. What a specific union pays depends on the modules and scope confirmed in discovery, which is also where accounting export targets, remittance formats, and disbursement structure are mapped to how the union actually runs.

Two client outcomes are worth stating plainly, because they are the kind of specific result this whole guide argues for. At ILWU Local 13, moving off a legacy system onto eMembership eliminated manual remittance entry that had previously meant thousands of records keyed by hand every month, and removed the need for temporary staff that manual data entry had required. And at a Workers United joint board of roughly 5,000 members, the controller reported that adding new members, recording remittances, and withdrawing terminated members went from nearly two full days to a little over half a day per month.

On collection accuracy, eMembership was part of what changed the underlying data quality and process at SEIU Local 105. As the local's Director of Operations put it:

eMembership has helped us increase the accuracy of our data and dues collection process for our members and the contracts that we manage. This has increased our collection rate and the overall efficiency of our membership team.
— Carey M., Director of Operations, SEIU Local 105

Whether eMembership is the right fit depends on a union's size, structure, and how much it values having dues connected to member, employer, and contract records in one system. The Discovery Process exists to determine exactly that, and which modules a given union actually needs. To go deeper on the mechanics, see our union dues software overview for the compliance and employer-remittance side, the Member Payments and Billing module and the member database the dues system reads from. If member-side dues payment is part of your goal, the member self-service portal guide covers how members pay and check standing on their own. And because UnionWare is the platform most often raised on dues-billing questions, our eMembership vs. UnionWare comparison lays out where each fits.

Frequently asked questions

Can we report member and employer balances and receivables by accounting period?
Yes, in a configuration that assesses a fee and applies payments against it, which also supports dual checkoff and self-pay in the same system. Balances can be tracked by number, by paid-through date, or by status, and reported either by member or by employer. The right approach for your union is set during discovery.
Does eMembership export to our accounting system?
Yes. The export is a configurable CSV or Excel file with general-ledger mapping, scoped during discovery to your chart of accounts. eMembership has integrated with Great Plains, Sage, and QuickBooks. The specific target format is confirmed as part of implementation.
Can per-capita and disbursement splits be sent to a lodge, a district, and an international separately?
Yes. Per-capita can be configured as flat or percentage, at the lodge, contract, employer, or member level, with disbursement splits to the levels your structure requires and split dues calculated automatically.
Can we manage strike pay through the system?
Yes. Members on strike can be identified through member queries, and strike pay can then be produced either by printing checks from a template or by exporting to your accounting system.
What is the minimum set of modules needed to run dues and finance?
A dues and finance configuration generally needs members, employers, one hierarchy element such as a building or work site, a local breakdown, an administration section, and finance. eMembership is configured to the modules a union actually needs through a paid Discovery Process rather than sold as a fixed bundle.
Is every dues change tracked for audit?
Every change is logged with the user, the timestamp, and the old and new values. There is no one-click rollback; point-in-time restores are supported through nightly backups, handled with the support team. The absence of a blunt rollback is deliberate, since an audited change history is more defensible than a silent undo.
David Stone · eMembership

Want to see dues billing that connects to your member data?

Start with a short intro call. We will walk through how eMembership handles automated dues billing and learn about your union's current setup before anything else.

Book an Intro Call