Michpal: The Attendance Import and the Accounting Export

Michpal is an Israeli payroll product with attendance and pension modules alongside it, and it sits between two file doors: attendance reports coming in from time clocks, and payroll results going out to bookkeeping. Michpal publishes no record layout for either, so both doors are configured once with the vendor and then repeat monthly.

The two doors: what goes in and what comes out

Michpal is a payroll house product - the vendor states it produces well over a million payslips a month - and its published module list covers payroll, pension, a portal, attendance, a time clock, a professional knowledge service and a field-employee variant. For integration purposes only two directions matter:

• Inbound, per period. Hours and absence quantities per employee per salary component, produced by whatever collects attendance.
• Inbound, on change. Employee master data - a new hire, a bank account change, a tax status change.
• Outbound, per period. The payroll journal entry for bookkeeping, plus whatever reports finance needs.

Those three have completely different rhythms, and the most common architectural mistake is building one mechanism for all of them. Master data changes when a person changes; the period file moves once a month against a hard deadline; the journal entry is produced only after payroll is approved and must never run twice.

What does the Michpal interface file look like?

Michpal does not publish it. The public site is product material with no file structure, field list, character encoding or API description on it.

What is published sits on the sending side. JB Clock, an Israeli time-clock vendor, publishes a page listing the interface file it generates per payroll program:

Two things follow from that table. First, a file name is not a specification - knowing the file is called QDIV tells you nothing about its columns, and you still need the layout from Michpal or from the clock vendor's support. Second, the fact that every payroll program has a different file name is the whole reason attendance vendors sell "an interface" as a configured service rather than as a documented format. The generic version of that file, field family by field family, is in the attendance-to-payroll interface file.

The one-time setup that decides whether the monthly run works

The clock vendor's own page is explicit that the interface requires a one-time definition: the company number in the payroll program, the various salary components (100%, 125%, 150%, 200%) together with vacation, sick, reserve, absence and travel components, and per employee the employee number as it exists in payroll.

That is the whole project, compressed into one sentence. Expanded:

The row that costs the most is the last one in practice, because it produces a small, plausible error every single month rather than an obvious failure once.

Employee master data: the other inbound door

Attendance is not the only thing that has to reach Michpal. New employees, bank details and tax status have to arrive too, and there is at least one publicly documented path.

The HR product Ovdim publishes an integration page describing an export into Michpal in XLSX or XML, with the file named employees_[company_number] plus the format extension, after a one-time template is configured in Michpal's data-load settings. Its published field notes are unusually candid and worth reading before you assume any employee import is complete:

• Bank number, branch, account number, calculation symbol and salary basis are supported in the XLSX format only, not in the XML one.
• Roughly 40 Michpal-side fields - department, grade, seniority accrual, vacation and sick balances, discharge date and similar - are not covered by either format.
• On an update to an employee who already exists in Michpal, the salary basis is not changed.

That last rule is the kind of detail that decides an architecture. If the import cannot change salary basis for an existing employee, then salary basis is owned by payroll, not by the HR system, and your process has to say so out loud rather than assume the file will fix it.

Why does the same interface work in one company and fail in another?

Because the interface carries quantities, and the meaning of those quantities is defined in configuration that differs per company. Two organisations running identical software will disagree on:

• Whether the 100% component is hours or days.
• Whether a component code is reused with a different meaning in a second employing entity.
• Whether travel is a fixed monthly amount in payroll or a per-day quantity from attendance - if both sides think they own it, it is paid twice.
• Whether an employee moving between departments mid-month is one row or two.
• Whether a global company holiday reaches payroll as an absence code or as nothing at all.

None of these are bugs. They are unwritten agreements, and an interface is where unwritten agreements come to fail. Write them into a mapping document that both sides sign, and keep it next to the file, not in someone's memory.

Getting payroll results out to accounting

The outbound direction is a journal entry, and it has a property the inbound file does not: it must balance and it must post exactly once. Practical rules that hold regardless of which bookkeeping system receives it:

• Post the summary, not the payslips. Bookkeeping needs accounts and amounts, not names and salaries, and keeping identity data out of the journal narrows who has to be authorised to see it.
• Reconcile total debits to total credits before anything is sent. A journal that does not balance is rejected downstream, usually after hours.
• Keep the period stamp on the entry, not the export date, so a re-run in the following month still posts to the right month.
• Record which run produced which entry, so a correction can be traced instead of re-posted.

If the receiving system is Hashavshevet, its own interface behaviour is covered in the Hashavshevet API integration guide. The wider month-end sequence, from collection through to approval, is in how to automate payroll.

Sources

• Michpal attendance module
• Interface to payroll software - JB Clock
• Ovdim - Michpal integration documentation