Timecard CSV formats: what each payroll provider expects

Why the layouts differ at all

A payroll provider is not reading your timecard for its own sake. It is loading rows into a pay engine that already knows the contract, the union agreement and the account coding for the production. The CSV is the narrow part of that pipe, so each provider shaped it around whatever its engine needs first.

That produces three real splits. Time of day is written as military time by some and as ordinary punches by others. A meal break is captured as a duration in minutes by some and as an out-and-in pair by others, which is the difference between recording that a crew member took thirty minutes and recording exactly when. Overtime is computed by the provider in one case and expected pre-split in another.

The layouts side by side

These are the exact columns Breadshift writes for each provider, read from the export code itself:

Where they diverge

GreenSlate is the outlier worth planning for. Its import carries separate straight-time, time-and-a-half and double-time columns, so something upstream has to decide where the boundaries fall. Cast & Crew takes hours as a decimal, which means a wrap at 18:45 has to become 0.75 of an hour before it reaches the file rather than after.

EP asks for six punches rather than two. If your crew only ever record call and wrap, the meal punches have to be reconstructed from a duration, and a reconstruction is a guess about when the break started.

What every one of them wants

Despite the differences, four groups of field appear in all of them:

• Project coding. A project number or code, and for three of the four an account or cost code alongside it. This is how the cost lands in the right budget line.
• Identity, partially masked. Last four of the SSN, and for a loan-out the company name plus the last four of its FEIN. Full numbers are not in the file.
• Union classification. Local and member ID, plus an occupation or position code. Dues and rate floors hang off this.
• Rate basis. The rate itself is not enough; the provider needs to know whether it is daily, hourly or weekly, and whether a kit or box rental rides alongside it.

What makes an import bounce

In practice the rejections cluster:

• A missing project or account code, which the provider cannot infer.
• A loan-out marked yes with no FEIN, or a FEIN with no company name.
• A union member with a local but no ID, or an ID with no local.
• A wrap time earlier than the call time, which is a post-midnight wrap recorded without the day it belongs to.
• A rate with no basis, which the engine will not assume.

The post-midnight case is the one that quietly produces wrong pay rather than a rejection. A wrap at 02:10 belongs to the previous work date, and a system that stores wrap as a bare time on the same date will read it as a negative day or a two-hour one, depending on how the arithmetic falls.

How Breadshift handles it

The five layouts above are built in, and the export screen checks the rows before it writes the file: it lists the fields a given provider needs that are missing, and how many rows are affected, so the gaps are visible before the accountant is the one to find them.

If your provider is not one of the four, the generic layout carries every payroll-adjacent field the app holds, which is usually a superset of what an unlisted provider or an accountant asks for.