Meckano and Time Clocks: Automating the Monthly Review Before Payroll

The month-end attendance review is the last point at which an error is cheap to fix. Automating it means producing a short exception list - missing punches, shifts crossing midnight, people with no payroll number, components that appeared from nowhere - and requiring a decision on each one before the payroll file is generated at all.

The monthly cycle, and where the review actually belongs

The cycle has five stages, and the review is the third, not the last:

• Collection, running continuously through the period from clocks, apps, browsers and phones.
• Closing the period, a decision that a date range is now complete.
• Review and exception handling, where anomalies are surfaced and resolved.
• Approval, by the manager who is accountable for the hours.
• Export to payroll, once, after approval.

Teams that put the review after the export end up correcting inside payroll, which is the most expensive place to correct anything, because the correction now has to be reflected in two systems that disagree. The rest of the close sequence is described in how to automate payroll.

The anomalies worth detecting automatically

Eight rules cover most of what actually goes wrong. Add a ninth only when you have seen the failure at least twice, because every rule that fires without teaching anyone anything trains people to click through the list.

What can Meckano's API actually do for this?

Meckano publishes that it offers a REST-based web service and that a user requests a key for their account, which is used to identify the client, with the usual create, read, update and delete operations over HTTP calls. It describes exported data being usable in resource planning systems and mentions analysis of hours, absences, reports and locations.

What it does not publish is a link to documentation, an endpoint list, a schema, rate limits or an authentication example. So the honest planning position is:

• An API exists and is described by the vendor as REST with a per-account key. That much is documented.
• The specific calls you need are not public. Request the documentation from Meckano before estimating, and treat any estimate made without it as provisional.
• Because the vendor also supplies the payroll export as a product feature, check whether you need the API at all. Pulling data out to rebuild an export the product already produces is a common and avoidable expense.
• Where an API is available, the useful thing to build is the exception query, not a replacement export - reading data to detect anomalies is low risk, writing corrections back is not.

Standard export or a custom wizard?

Meckano's payroll wizard page describes both: a standard payroll export with a ready data structure aligned to most payroll systems, and a custom payroll wizard for organisations with more complex requirements. It names Michpal, Hilan, Shiklulit and Oketz among the payroll systems it works with, and describes the flow as collecting hours, processing the data, generating the payroll file and exporting automatically.

Choose the standard export when your payroll setup is ordinary: one employing entity, standard overtime tiers, absences from a familiar list. Choose the custom route when at least one of these is true:

• More than one employing entity shares an employee population.
• Component mapping differs by site, union agreement or job family.
• Some quantities come from outside attendance entirely - production output, project allocations, incentive data.
• Hours have to reach a second destination, such as project costing, in a different shape from the payroll file.

The important part is to make that decision explicitly, once, and to write the mapping down. The general anatomy of the file the wizard produces is in the attendance-to-payroll interface file.

Who fixes what, and by when

An exception list with no deadline is a report, and reports get read after the close. The pattern that works is a short, published timetable with a named role per row:

• Period closes on a fixed day, and the closing is a system action, not an email.
• Employees have a fixed window to correct their own missing punches. After it, corrections require a manager.
• Managers approve within a fixed window. Silence is not approval - an unapproved department blocks its own rows, not the whole run.
• Payroll runs the pre-export checks - employee list reconciliation, component variance, totals - and only then generates the file.
• Everything unresolved at the deadline follows one written rule, agreed in advance, rather than an ad-hoc decision under time pressure.

For accountants and payroll bureaus handling many companies, the same timetable repeats per client, which is why Meckano's accountants' interface emphasises moving quickly between companies and exporting attendance reports for each. The multi-client version fails on calendar management long before it fails on data.

What to measure so the review gets shorter every month

Track four numbers per period, and the review shrinks on its own:

• Exception count per hundred employees, split by rule, so you can see which rule is actually earning its place.
• How many exceptions were resolved before the deadline, which measures the process rather than the data.
• Corrections made after export, which is the number that matters, because each one is a two-system correction.
• Repeat offenders by rule - if the same three people generate half the missing punches every month, the fix is a clock placement or a schedule, not a report.

Publishing these makes the argument for a change without anyone having to make a case from memory. Related patterns for HR-side automation are collected in automation for HR teams.

Sources

• Meckano - API for developers
• Meckano - payroll wizard
• Meckano - accountants interface