What is actually inside a monthly attendance-to-payroll file, why every vendor's layout differs, the dates that govern it and the errors that repeat monthly.
Key takeaways
- The file answers one question per row: which employee, which component, how much. Rates, tax and calculation stay on the payroll side.
- Layouts are per-payroll-program. A time-clock vendor publishes that its file is named QDIV for Michpal, TAMAL.DAT for Shiklulit-Tamal and SALxxxxx.MM for Trio-Oketz - different names because they are different formats.
- Almost none of these layouts are published. Where an inbound file is documented, it is documented by the receiving product: Rivhit's knowledge base describes importing a clock file named KLT.TXT built to an ASCII structure through a specific menu path.
- The interface is governed by a calendar as much as by a format. Period boundaries, the correction window and the approval deadline cause more failures than field types do.
- Compare that with the pension employer-reporting file, whose XML structure is published by the Capital Market Authority. A regulator-defined interface is documented; a vendor-defined one usually is not.
An attendance-to-payroll interface file is a per-period list saying, for each employee, how much of each salary component to pay. It carries quantities and codes, not money and not calculations. Its layout is defined by the receiving payroll program, differs between vendors, and is almost never published - which is why the same handful of errors recurs monthly.
What is in an attendance-to-payroll interface file?
One row per employee per component per period, in the simplest and most common design. Nothing in it should require the sender to know anything about money.
That constraint is the single most useful rule when designing or reviewing one. If the file contains an amount in shekels, someone has calculated pay outside payroll, and there are now two systems that can produce a different answer for the same person. Quantities and codes only, and let the payroll program apply the rate it holds.
The row is therefore made of five field families, and every real-world layout is some arrangement of them.
The five field families
- Identity. The employee number as it exists in the payroll program, and the employing entity or company number. A clock or badge number belongs on the sending side only, and ת"ז should travel only if the receiving process genuinely requires it - this file is personal data and the field list is part of what makes it more or less sensitive.
- Period. The month and year the quantities belong to, and sometimes a date within it. A file without an explicit period is a file that can be loaded into the wrong month.
- Component. The salary component code, which is the agreed vocabulary between the two systems: base hours, overtime tiers, vacation, sick, reserve duty, absence, travel and whatever else the organisation pays.
- Quantity. Hours, days or units. The unit is a property of the component, and it must be agreed per component rather than assumed across the file.
- Control. Record count, total per component, and a run or version identifier. Control fields are what let the receiving side prove nothing was lost, and they are the family most often omitted.
Two extras appear when the organisation needs them: a cost centre or project code where hours are allocated beyond payroll, and a correction flag distinguishing a new quantity from a replacement of an earlier one.
Why is every vendor's file different?
Because the format belongs to the receiving payroll program, not to a standard. There is no cross-vendor Israeli standard for attendance-to-payroll input, and the evidence is visible in the file names themselves.
| Receiving payroll program | Interface file name published by a time-clock vendor |
|---|---|
| Michpal | QDIV |
| Shiklulit - Tamal | TAMAL.DAT |
| Trio - Oketz | SALxxxxx.MM |
| Hilan | listed, no file name published |
The same vendor's page also states what must be defined once before any of them will work: the company number in the payroll program, the salary components (100%, 125%, 150%, 200% together with vacation, sick, reserve, absence, travel and others), and for every employee the employee number as it exists in payroll. Those three items are common to all the formats even though the formats differ - which tells you where the real work is.
Documentation does exist in places, usually published by the receiving product rather than the sender. Rivhit's knowledge base, for example, describes importing attendance data from an external system through a file named KLT.TXT built to an ASCII structure it details, reached through a specific menu path in the product. Its own API surface is covered separately in the Rivhit API integration guide. For the Michpal side of the same conversation, see the Michpal attendance and accounting interface.
The monthly cycle in dates, not stages
| Point in the cycle | What must be true | What goes wrong if it is not |
|---|---|---|
| Period boundary | Every shift is assigned to exactly one period | Overnight shifts on the last day land in the wrong month, permanently |
| Correction window closes | Employees can no longer edit their own records | Late edits change data after a manager has approved it |
| Approval | A named manager has approved each department | Hours are exported that nobody stands behind |
| Pre-export checks | Employee lists reconcile, totals are within tolerance | The file loads cleanly and is wrong |
| File generated | Exactly one file per period per entity | A second file is produced "to be safe" and loaded twice |
| Payroll loaded | The receiving side confirms the record count | Nobody knows whether all rows arrived |
The row that surprises people is the last. A file that loads without an error message has not necessarily loaded completely, and only a control total will tell you the difference.
The errors that come back every month
| Error | Root cause | The check that catches it |
|---|---|---|
| Employee missing from the run | No payroll employee number on the attendance record | Reconcile both employee lists before generating |
| Hours in the wrong month | Shift crossing midnight at the period boundary | Assign shifts by start time, and test the boundary every month |
| Overtime paid at base rate | Component mapping missing a tier | Compare component totals month on month |
| Travel or allowance paid twice | Both systems believe they own the component | One written owner per component |
| Loaded twice | Regeneration after a partial load | Unique run identifier, and refuse a duplicate |
| Silently truncated file | Encoding or transfer failure | Record count in the control record, verified on load |
| Absence charged to the wrong balance | Two absence codes with similar names | Code list reviewed whenever a code is added |
| Numbers wrong after a vendor upgrade | A column added in the middle of the layout | Version stamp, and a rule that new columns append at the end |
Eight items, and none of them are exotic. They repeat because the interface is treated as a technical artefact when most of them are actually failures of an agreement between two teams. The operational review that catches most of them before the file exists is described in automating the monthly attendance review.
Making the file provable
Provable means that a year later you can answer "where did this number come from" without asking anyone to remember. Four practices get you there:
- Keep every file you sent, exactly as sent, with its period and run identifier. Storage is cheaper than a reconstruction.
- Log the load result on the receiving side, including the record count accepted, so a mismatch is discoverable rather than theoretical.
- Version the layout, and stamp the version in the file name or in a header record. Layouts change; undated layouts cannot be reasoned about.
- Reconcile one total automatically each period between the attendance system and payroll, and report the result whether or not it matched. A reconciliation that only speaks when something is wrong is indistinguishable from one that has stopped running.
It is worth ending on the contrast: employer reporting of pension deposits in Israel runs on the Capital Market Authority's uniform structure, an XML-based format defined in published circulars, so anyone can read the definition before building. The attendance-to-payroll file is the opposite case - defined per vendor, rarely published, and agreed in a conversation. That is not a reason to avoid it. It is a reason to write the agreement down.
Sources
Frequently asked questions
Is there a standard format for attendance-to-payroll files in Israel?
No cross-vendor standard could be found. The receiving payroll program defines the layout, which is why a time-clock vendor publishes a different file name per payroll system. Obtain the layout from the payroll vendor or from the attendance supplier that already produces it.
Should the file contain amounts in shekels?
As a rule, no. Sending quantities and component codes keeps the calculation in one place. An amount in the file means pay was calculated outside payroll, which creates two systems capable of producing different answers for the same employee.
How do I stop a file being loaded twice?
Give every generated file a unique run identifier, record on the receiving side which identifiers have been loaded, and refuse a repeat. Regenerating after a partial load is the common trigger, so a partial load must be an explicit state, not a silent one.
What causes hours to land in the wrong month?
Shifts that cross midnight at the period boundary. Decide once whether a shift belongs to its start date or its end date, write that rule down, apply it in the export, and test the boundary every period rather than assuming last month's behaviour holds.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.