Shiklulit and Maskoreshet: Employee Cards and Payroll Input Interfaces

Payroll input splits into two things that are constantly treated as one: the employee card, which is master data that changes when a person changes, and the monthly variable input, which arrives every period. Shiklulit, by Tamal, documents Excel import and attendance interfaces. Maskoreshet documents a per-month salary screen and a configurable journal-entry export.

The employee card is master data, the monthly input is not

An employee card holds identity, tax status, bank details, employment terms and the salary basis. Monthly input holds quantities: hours, absences, one-off payments, deductions. They differ on every axis that matters to an integration:

• Frequency. The card changes a handful of times per employee per year. The input moves every period without exception.
• Owner. HR or the manager owns the card. Attendance and payroll own the input.
• Consequence of an error. A wrong card silently repeats every month until someone notices. A wrong input is usually caught in the same period, because the payslip looks odd.
• Correction path. A card is corrected forward. An input is corrected by rerunning the period or by a retro adjustment.
• Sensitivity. The card carries ת"ז, address and bank details. The input carries far less identity data and can often be moved with a narrower field set.

That last point is worth designing around: if the monthly interface does not need identity fields, do not put them in it. Fewer copies of personal data is simply less to manage. The wider onboarding sequence around the card is in an employee onboarding workflow across teams.

What Shiklulit accepts as input

Shiklulit is a payroll product from Tamal, and its published page is unusually explicit about interfaces, which makes it a useful reference point:

• An interface with the common attendance programs, described as importing employees' attendance data at the press of a button.
• Import of payroll data and employee details via Excel.
• An automatic interface with provident, pension and study funds for reporting contributions.
• A transmission interface for טופס 102 to the Tax Authority, and טופס 161 transmission.
• Report output to PDF and Excel, a report generator and pivot tables.
• Shiklulit Up, an employee portal covering טופס 101, payslips and טופס 106.

What is not published is the structure of any of those files - no column list, no encoding, no sample layout. A time-clock vendor publishes that its Shiklulit-Tamal interface file is named TAMAL.DAT, which confirms a file-based interface exists and stops there. So the practical position is: the capability is documented, the format is not, and the format comes from the vendor or from the attendance supplier who already produces it.

Can you bulk-load employee cards into Maskoreshet?

Its published help page for loading an employee's salary describes manual entry only. You reach the screen through the employee list by clicking the salary column on that employee's row, and the page describes no file import, batch upload or external connector.

What it does describe are two mechanisms that reduce the manual work without a file:

• A salary template. A preset can be defined and applied to new employees, which standardises how a role is set up rather than retyping it.
• Copy forward. On the transition to a new work month, the previous month's salary is copied automatically into the new month and marked "לא טופל" until it is handled. Employees who have left do not require entry for subsequent periods.

For a small or mid-sized payroll, that combination is often faster than an import project. It becomes a problem at the point where employee data genuinely originates elsewhere - in an HR system, in a hiring flow - because then every hire is typed twice, and the second typing is where the errors live.

Side by side: what goes in and what comes out

The row that matters most for a build is the last one. Both vendors describe outputs; neither publishes a layout. So in both cases the deliverable you should ask for by name is a sample file plus a written field definition, and you should ask for it before agreeing a price.

Why does the second month behave differently from the first?

Because the first month is entered and every month after it is inherited. Maskoreshet makes that explicit with the copy-forward and the "לא טופל" state, but the pattern exists in every payroll product, and it produces a distinct class of error:

• A one-off payment entered in month one quietly repeats in month two if the copy is approved without review.
• A component that should have ended - a temporary allowance, a loan repayment, a training deduction - carries on because nothing told it to stop.
• A person who left is still carried until someone marks the departure, and the system's own rule is that leavers need no entry for later periods only once they are recorded as having left.
• An input that arrives from attendance overwrites a manual correction made after the previous run, unless the order of operations is fixed.

The control that catches all four is not clever: a month-on-month variance report per employee per component, reviewed before approval, with a threshold that forces a human to look. Anything that appears this month and did not appear last month, or that changed by more than the threshold, gets a reason written next to it.

The output nobody plans for: the journal-entry file

Payroll's real integration point with the rest of finance is the journal entry, and Maskoreshet's help page is specific about how that works there. Transactions are produced according to the accounts defined for each section, and a transactions file can be produced in a choice of file structures selected from a menu. One of those structures, "חשבשבת שיטה גמישה", additionally requires a movein.prm file - a real, checkable detail of the kind you will not find on a marketing page.

The account mapping is defined at three levels: a general level for a section total, a detail level per component, employee or affiliation, and a further detail level for an individual employee or affiliation. Transferring the data to bookkeeping requires accounts to be defined there for every section, and debits must equal credits, with a mismatch shown in red.

Three consequences for anyone automating around it:

• The mapping is configuration, not code. It changes when the chart of accounts changes, and it has to be reviewed whenever a new salary component is introduced.
• A file structure is a contract with the receiving system. Choosing the wrong one produces a file that looks fine and imports wrongly. The Hashavshevet side of that conversation is in the Hashavshevet API integration guide.
• The balance check is a gate, not a report. Nothing should be sent onward while it fails.

Where the receiving system is Sumit, its own interface behaviour is covered in the Sumit API integration guide.

Sources

• Shiklulit payroll software - Tamal
• Maskoreshet - loading an employee's salary
• Maskoreshet - payroll journal entry for bookkeeping