Union and Multiemployer Pension Remittance Files

Every employer with a collective bargaining agreement owes a fund something each month: a file that says who worked, how many hours counted, and what the employer is paying in, plus the payment itself. The file is small. The exposure behind it is not. A remittance that is late, short, or built on the wrong hours definition is a delinquency under federal law, and the fund can collect the shortfall, interest, liquidated damages, and the cost of the audit that found it.

This guide covers what a remittance file is, what it carries, the hours definition that drives every number in it, who belongs on it, how to build it from payroll, the checks to run before sending, what happens when a fund audits, and how the process runs on Praisidio.

What a remittance is

A multiemployer plan is a benefit fund that many employers pay into under one or more collective bargaining agreements. Pension funds are the best known, but the same structure covers health and welfare funds, apprenticeship and training funds, annuity and supplemental retirement funds, and industry promotion funds. Each fund has trustees, a plan document, and a schedule of employer contributions tied to the CBA.

The remittance is the periodic report and payment. Most funds bill monthly; some construction and hospitality agreements bill weekly or by pay period. The contribution is computed on a base the CBA defines: usually hours, sometimes a percentage of gross wages, occasionally a flat amount per employee per month. A single CBA can feed several funds with different bases, so one bargaining unit may produce three or four remittance files each month.

The legal weight comes from ERISA section 515, codified at 29 U.S.C. 1145: every employer obligated to contribute to a multiemployer plan under the plan or a collective bargaining agreement must make those contributions in accordance with the terms of the plan or agreement. A multiemployer plan, under 29 U.S.C. 1002(37), is one to which more than one employer is required to contribute and which is maintained under one or more collective bargaining agreements.

When a fund sues to collect and wins, the award is mandatory rather than discretionary. ERISA section 502(g)(2), at 29 U.S.C. 1132(g)(2), requires the court to award the plan the unpaid contributions, interest on them, an amount equal to the greater of that interest or liquidated damages provided for under the plan (not more than 20 percent of the unpaid contributions, unless federal or state law permits a higher percentage), reasonable attorney's fees and costs, and any other relief the court finds appropriate. Interest runs at the rate the plan provides, or at the federal underpayment rate under 26 U.S.C. 6621 if the plan is silent. Most plan collection policies also charge the employer for the audit that uncovered the shortfall. That is why the file has to be right before it goes, not corrected after.

What the file carries

Funds specify their own layouts, and they vary from a fixed-width text file to a spreadsheet the fund's portal accepts. The content is more consistent than the format. A typical monthly file has one row per employee with:

• Employee identifier. Often the Social Security number, sometimes a union member number or a fund-assigned ID. Some funds require both.
• Name, in the fund's order, usually last name first.
• Date of hire, so the fund can apply eligibility waiting periods and vesting.
• Date of birth, for retirement eligibility and age-banded benefits.
• Classification or job code, which selects the contribution rate.
• Hours for the period, as defined by the CBA.
• Contribution amount, hours times rate, or the dollar base and percentage for wage-based funds.
• Sometimes gross wages, status changes such as new hire, termination, or leave, and a work location or project code.

The worked example in this guide is a monthly Excel layout with columns for SSN, last name, first name, date of hire, date of birth, classification, hours, and contribution. Many funds require the file without a header row, and many reject rows where SSN or date of birth is blank, so those are validation rules rather than cosmetic points.

One row per employee per month is the common shape, but some funds want weekly rows or one row per classification. Read the fund's layout before assuming.

The hours question

Everything in the file follows from what counts as an hour. The CBA answers this, and the answer is different for almost every agreement.

Paid hours or hours worked. Some agreements count every paid hour, including vacation, holiday, sick, and bereavement. Others count only hours actually worked. Many are in between: holiday and vacation count, sick does not, or paid time off counts up to a stated number of hours per year.

Overtime. Three treatments are common. Overtime hours count once, as hours, regardless of the premium paid. Overtime hours do not count at all. Overtime hours count at the premium rate, so a double-time hour counts as two. The third is rare for hours-based pension funds and common for wage-based funds, where the premium is part of gross wages.

The monthly cap. Some plans cap countable hours per employee per month, often at 160 or 173.33, so that a heavy overtime month does not produce contributions beyond a full-time equivalent. Others have no cap.

Probationary periods. Many agreements exempt new hires from contributions for the first 30, 60, or 90 days, or until a set number of hours. Contributions then begin from the first day of the month after the period ends, or from the day itself, depending on the agreement. The hire date in the file is what lets the fund verify this.

Different rules per fund. The pension fund and the health and welfare fund under the same CBA can count hours differently. The training fund may count only hours in apprentice classifications.

These rules have to be encoded per classification, per fund, with effective dates, because agreements are renegotiated and rates and rules change mid-year, and that month's file has to apply each change to the right days.

Who is covered

The bargaining unit is defined by job classification and, often, by location or division. The file must include every employee in the unit who had countable hours in the period and nobody else. The hard cases are the boundaries:

• Employees who move in or out of the unit mid-month. A promotion from a covered classification to a supervisory one, or a transfer between locations, means hours before the change count and hours after do not. The file needs the effective date of the change, which lives in the employee change log, not on the current employee record.
• Terminated employees with hours in the month. They appear for their final month with their final hours, and not again. An employee who appears in the month after termination is a finding.
• Rehires. The probationary rule may or may not restart on rehire; the agreement says. The fund matches on SSN, so a rehire with a new employee ID still has to carry the same SSN and the original hire date if the agreement uses it.
• Two classifications in one month. An employee who works some hours as a journeyman and some as a foreman, at different rates, needs either two rows or a blended row, depending on the layout. The hours have to be split by the earning code or the job code on the time record, not allocated by ratio.
• Non-unit employees with unit earning codes. A salaried employee paid a union code by mistake will appear in a naive extract. Classification on the employee record is the filter; earning codes are the cross-check.

Building it from payroll

The file is a join of four things, and each has a home in the payroll data.

Hours by earning code per employee per month come from the earning history table: one row per employee, pay date, and earning code, with hours and amount. Whether the month is defined by pay date or by period end date is itself a CBA question; most funds go by the period worked, and a pay period that straddles the month boundary is split by day or allocated to the month it ends in, whichever the fund accepts.

Classification comes from the employee record: job title code, union code, or a fund-specific classification field. Where it changed during the month, the change log gives the effective date.

The countable code list is configuration: which earning codes count as hours for this fund, and whether overtime codes count once, not at all, or at the premium multiple. This list is different for the pension fund and the health fund and has to be maintained per fund.

The rate table is configuration too: contribution rate by classification by effective date, plus the cap and the probationary rule. When the CBA is renegotiated, a new effective-dated row is added and old months still compute with the old rate.

From those four, the contribution per employee is countable hours, capped where the plan caps, times the rate for the classification on each day, rounded as the fund specifies. Rounding at the wrong step, per row versus per total or hours to the quarter hour first, produces a file a few cents off the fund's own calculation every month, which is an audit finding even when the money is trivial.

The last step is the general ledger. The remittance total should reconcile to the accrual booked in payroll for the month, by fund. A difference means either the accrual used a different hours definition or the file is missing people.

The checks before sending

Run these every month, in this order, before the file leaves.

1. Every employee in a covered classification with countable hours in the month has a row. The list of covered employees is the employee table filtered by classification and location; anyone with hours and no row is a missed contribution.
2. No employee outside the unit has a row. Anyone with a row whose classification is not covered is a mis-coded earning or a stale classification.
3. Hours on the file reconcile to earning history by employee and code. The sum of countable hours in the file equals the sum in the history for the same codes and period.
4. Contribution equals hours times rate within the fund's rounding for every row, and the total equals the sum of rows.
5. No blank SSN, date of birth, or date of hire. Funds reject these rows, and a rejected row is a late contribution.
6. No employee over the monthly cap where the plan caps hours.
7. No terminated employee appears in a month after their termination month. No employee on unpaid leave appears with hours.
8. Month-over-month headcount and total hours are within a reasonable band. A large unexplained swing usually means a code list or classification change went wrong.
9. Rate table effective dates cover the whole month. A month that straddles a rate change should show two rates in the detail, not one.
10. The general ledger accrual for the fund matches the file total.

Delinquency and fund audits

The audit cycle and the look-back are set by the plan's trust agreement and its collection policy, not by statute, so read those documents rather than assuming a schedule. Three-year cycles are common, and audits are also triggered by a complaint, a sale of the business, or a pattern of late or short payments. The auditor asks for the payroll registers for the period, the time records behind the hours, the employee list with classifications and dates, the CBA and any side letters, and the remittance files as sent. They rebuild the contribution from the registers and compare it to what was paid.

The look-back is usually the full period since the last audit, and collection policies commonly reach back six years, which tracks the limitations period many courts apply to section 515 claims. That means the employer has to be able to reproduce any month's file from the payroll data as it stood, with the code list and rate table that applied then.

Common findings are the ones the checks above target: covered employees never reported, hours excluded because the countable code list was wrong, contributions at a stale rate after a renegotiation, and terminated employees reported for extra months. Each carries interest and liquidated damages, and the employer usually pays the audit cost. The defense is a file built from payroll data every month by a stated rule, with the detail behind each row available on request.

How Praisidio helps

The remittance is a report template with the month as its only parameter. It runs against two tables that already exist for every payroll customer: the earning history (employee, pay date, earning code, hours, amount) and the employee record (classification, union code, hire, rehire, and termination dates, work location). Nothing is re-keyed.

Everything the CBA decides is configuration, not code: the countable hour codes per fund with the overtime treatment, the contribution rate by classification with an effective date (a renegotiation is a new row, so old months still compute at the old rate), the monthly cap, and the probationary rule. When the agreement changes, the configuration changes and the template does not.

The export matches the fund's column layout and sequence, with the header row excluded where the fund's portal rejects one. Weekly rows or one row per classification are variants of the same template, not a second build.

Behind the template sits a debug collection that answers the question a fund auditor actually asks: where did this row come from. It lists, per employee per month, the hours by earning code, the classification that applied on each day, the rate used, and the rounding, so any figure on the file traces to specific pay records. The pre-send checks from section 6 are separate reports in the same collection: covered employees with hours but no row, rows for people outside the unit, hours that do not reconcile to earning history, rows where contribution does not equal hours times rate, blank SSN or date of birth or hire date, employees over the monthly cap, rows after a termination month, and month-over-month headcount and hours swings outside the expected band. The preparer clears those lists, then exports.

Because the month is a parameter and the configuration is effective-dated, any past month can be regenerated as it was produced at the time. A fund audit asking for three years of detail is thirty-six runs of the same report, not a reconstruction from archived spreadsheets.

Monthly checklist

• Rate table and countable code list confirmed current for the month, including any mid-month change
• Covered classification and location list confirmed against the CBA
• File generated from earning history for the correct period definition
• Every covered employee with countable hours present; no non-unit employees present
• Hours reconcile to earning history by code
• Contribution equals hours times rate within rounding; total equals sum of rows
• No blank SSN, date of birth, or date of hire
• No employee over the monthly cap; no post-termination or unpaid-leave rows
• Headcount and hours within expected band versus prior month
• File total reconciles to the general ledger accrual
• File exported in the fund's layout, header excluded where required, and retained with the detail behind it

Frequently asked questions