Union Membership and Dues Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does dues get scoped as a subscription so often?

Because every generic system models recurring revenue that way, and on a demo it looks close enough. A rate on the member record, a monthly charge, a balance. It is wrong in a way that only becomes visible after go live.

Dues in this sector are contract terms. One agreement charges a percentage of gross wages capped at a monthly maximum. Another charges two hours pay per month at the member's classified rate, with a different rate for apprentices and another for part timers and retirees. A third adds a working dues assessment on hours worked that applies only to members under one of your four agreements. Every one of those is a formula whose inputs arrive on an employer remittance, and every one changes when the agreement is renegotiated.

The fix: make the collective agreement a first class object with an effective period, and attach dues rules to it rather than to the member. A member's dues then derive from their classification, their employer, the applicable agreement and the reported earnings or hours for the period. When an agreement is renegotiated you add a version with an effective date, and historical periods stay computed the way they actually were. This matters beyond accuracy: when a member disputes an arrears figure you can show the agreement, the rule version, the classification, the hours and the amount. A number without a derivation is an argument. A number with one usually ends the conversation.

What goes wrong with remittance data and member identity?

Employers remit on their own schedule in their own format. One sends a clean file. One sends a document that used to be a spreadsheet. One sends a bank transfer with a total and no detail at all. Names arrive as Mike where your roll says Michael, as married names where you hold maiden names, and as payroll identifiers that exist nowhere in your system. Someone who left in March is still on the remittance in May, and someone hired in April is on none of them.

So the membership team spends the first two weeks of every month matching, and the real cost is not the effort. It is that the answer arrives too late to act on. A member who fell off an employer's file has been unrepresented on the record for two months before anybody notices.

The fix: build the import layer to accept each employer's actual format, keep the raw file untouched as evidence, and normalise into remittance lines. Match on an employer identifier where one exists, then on a scored comparison of name, date of birth and worksite, then queue the remainder for a person with the decision remembered so the same member is not matched again next month. Then add the two features that change daily life: an exception alert when a member present last month is missing this month, and a variance alert when dues change materially without a classification change. Both are trivial once the data is structured and impossible from a stack of documents.

Why do the employer, banking and per capita integrations break after launch?

Employer files break because employers change payroll systems and nobody tells you. The column order shifts, a header is renamed, a new column appears in the middle, and an importer built against a fixed layout either fails loudly or, worse, silently maps the wrong field and posts hours as earnings. Banking breaks at reconciliation, where a lump sum transfer arrives with no detail and there is no rule for how to apply it across the members it was meant to cover.

Per capita reporting to the international breaks differently and more expensively. It is computed off a headcount, and the headcount is only as good as the reconciliation, so a month with an unresolved matching backlog produces a per capita figure that is wrong in a direction you cannot easily correct later.

The fix: validate every import against the file's own structure before accepting it, and reject on a header or column change rather than mapping by position. Reconcile totals: the sum of the remittance lines must equal the amount received, and any difference goes to a queue with an owner rather than into a suspense figure. Compute per capita from the reconciled population with an explicit as at date and retain what was reported, so a later correction is an adjustment with a reference rather than a restatement nobody can trace.

What happens when good standing and grievance deadlines are not covered?

Good standing is a derived state and it has consequences. It determines eligibility to vote and to hold office, and the conduct of internal union elections is itself regulated under federal law, so an eligibility list assembled from a spreadsheet is a risk rather than an inconvenience. Confirm your specific obligations with counsel, since they depend on your sector and structure.

Grievances carry a different clock. Contractual step deadlines vary by agreement, and a missed deadline can extinguish an otherwise meritorious grievance permanently. A generic case tool gives you a due date field and no understanding of why the date matters, no working day calendar, and no escalation before expiry. Seniority is the third consequential record: layoff order, recall rights, shift and vacation selection and, in many trades, the referral list that decides who gets dispatched. Members compare their position on that list and they find every error in it.

The fix: build good standing as a derived state with a full audit trail, so you can say this member was in good standing on this date because dues were paid through this period under this rule, and here is the remittance line that proves it. Compute the next grievance deadline from the agreement's own timelines, the triggering event date and the correct calendar, and escalate before it lands rather than reporting after. Make the seniority list reproducible as of any date, because a layoff in February is judged against February's list.

Should you build custom or configure what you already own?

If you have one or two employers, a single dues formula and under a couple of thousand members, buy. UnionWare has been built specifically for unions for a long time and understands membership, dues and grievances as one domain rather than as a customer relationship system with extra fields. It will handle that shape of local and the total cost sits far below a build. UnionTrack ENGAGE is stronger on member communication and organising, which is where a lot of union investment is going, and it is a reasonable answer if that is your priority.

Buy as well if the union has no capacity to own a product. A system this closely tied to constitutional rules needs an internal owner who knows the constitution, and without that person any build drifts.

Build when you take remittances from dozens of employers in incompatible formats, when dues formulas differ by agreement in ways that require monthly manual adjustment, when you run referral or dispatch lists with rules specific to your trade, when grievance deadlines have been missed, or when the international asks for reporting your current system cannot produce without a week of assembly.

How do hidden costs get into the quote?

The number of distinct collective agreements drives price far more than the number of members, and quotes are almost always written against member count. Remittance format variety is the second: each genuinely different file shape is real work, and the employer who sends a document rather than data is a separate problem again.

Referral and dispatch lists for building trades are the third and are effectively a second system with their own rules and a very attentive audience. Statutory financial reporting is the fourth, since producing the underlying figures for an annual filing saves weeks but has to be built to the form your organisation actually files. Migration is the fifth, and in this sector the outgoing system is often a database old enough to vote, with member history that cannot be exported cleanly.

The fix: write down every dues formula across every agreement before you take a quote, including the ones staff handle by hand each month, and ask for the price broken by agreement count and remittance format count. Ask what the number becomes when referral lists come in scope. Keep the first release to your largest employers by member count, leave grievances to phase two, and make member self service read only before allowing updates.

What separates a build that works from one that fails here?

Ask them to model dues for a member covered by an agreement charging two hours pay per month at the classified rate, with a different rate for apprentices and a working dues assessment on overtime hours. If the answer is a rate field on the member record, they have not understood that the contract is the object, and everything else they build will inherit that mistake.

Ask how they would reproduce the seniority list as it stood fourteen months ago. The answer should involve an event log rather than a nightly snapshot table somebody may have missed. Ask what they have done with messy inbound files and whether the original is kept untouched, because in a dispute with an employer about what was remitted the original file is the record that matters.

Ask about member data protection specifically. You hold employment status, earnings, worksite and sometimes health or accommodation information about people whose employers would find that data valuable, which makes role based access and access logging a core requirement rather than a setting. Then settle ownership before kickoff: the repository, the cloud accounts and the unrestricted right to hire another firm, in writing. A membership roll and a grievance history are institutional records, and access to them should never depend on a supplier's cooperation.