Read Your CSV Export Columns Before Payroll

You have the file open in a spreadsheet, twelve columns wide, and payroll is due in an hour. Before you paste anything into your payroll system, you want to know exactly what each number means and whether any of it is going to be wrong. Here are the questions people actually ask about the export, answered in order.

What does each column in the CSV actually mean?

Each row is one time entry: a worker's name, when they clocked in, when they clocked out, and how long that entry lasted. The name column identifies the person. The clock-in and clock-out columns are timestamps shown in your local time, even though the underlying data is stored in UTC, so a shift that crosses midnight reads correctly for you. The duration columns give you the length of the entry in two formats (more on that below). If you use tags, a tag column tells you what the entry was labeled with, and a worker group column tells you which group the person belongs to. That lets you filter by event, role, or program without hand-sorting rows.

The column layout never changes between exports. If you built a payroll import mapping last month, the same mapping works this month, because the column schema stays stable and columns are never renamed or reordered.

Why are there two duration columns, decimal and HH:MM?

Because payroll systems and humans read time differently, and the file gives you both so you never have to convert by hand. The HH:MM column shows 6:45 the way a person reads a shift. The decimal hours column shows the same length as 6.75, which is what most payroll and grant systems want when they multiply hours by a rate. Six hours and forty-five minutes is 6.75, not 6.45, and that is exactly the kind of mistake the second column prevents.

Check which format your payroll import expects before you paste. If it asks for decimal and you feed it HH:MM, every total will be wrong. If you ever need to convert a stray value or sanity-check a row, the decimal and HH:MM converter does it both directions.

How are breaks and lunches shown in the export?

Breaks appear as gaps between entries, not as a separate deduction column. When a worker clocks out for lunch and clocks back in, you get two rows: one entry before the break and one after. The unpaid gap between them simply is not counted, because no clock was running. So if someone worked 9:00 to 12:00, took an hour, then worked 1:00 to 5:00, the file shows a three-hour entry and a four-hour entry, seven hours total, with the lunch nowhere in the numbers.

This means you should sum a worker's rows to get their paid total for the period rather than reading a single line. If you want to model paid versus unpaid break rules before you commit, run the numbers through a lunch-break time calculator first.

What is the distinct-worker count for?

The distinct-worker count tells you how many different people clocked in during the period, which is the number you need for grant reporting and headcount questions. It is not the number of rows. One person who worked five shifts is five rows but one distinct worker. Grant reports and board summaries usually ask "how many people served," and this is that number, calculated for you so you do not deduplicate names by hand.

Will a forgotten clock-out inflate the hours in my file?

No. A forgotten clock-out is closed automatically at its start time plus your cutoff, never at the current moment, so a volunteer who left without tapping out cannot show a 40-hour entry. If someone clocked in at 6 p.m. and forgot to clock out, auto-close caps that entry at the cutoff you set instead of letting it run overnight. You will still want to eyeball any entry that hit the cap, because the real time worked might be shorter, but you will never accidentally pay someone for hours the clock invented.

What should I check before I import the file to payroll?

Check four things, in this order:

1. Date range. Confirm the export covers the exact pay period and nothing spills in from the shift before or after it.
2. Duration format. Match decimal or HH:MM to what your payroll import expects.
3. Capped entries. Scan for any entry that hit the auto-close cutoff and correct the ones you know were shorter.
4. Totals. Add up one or two workers by hand and compare against your own memory of the week to catch anything obviously off.

If the numbers pass those four checks, the file is ready. Kangaroo Clock does not move money and is not a payroll processor, so the export is the handoff point: you import it into whatever system cuts the checks. The full walkthrough for pulling the file lives on the page about how to download a CSV for payroll.

Can I check the math without waiting for payroll?

Yes. If you want to verify a two-week total before the file even exists, drop your in and out times into the time card calculator and compare. Doing the arithmetic once by hand builds trust in the export, and after a period or two you will glance at the totals and know they are right.