Employee Payments and Reimbursements: Controls That Prevent Double or Wrong Payment

A payment to an employee that is not salary - a travel reimbursement, a purchase the employee made, an advance - falls between two systems: it is not inside payroll and it is not a supplier in the books. That is exactly where double payments, undocumented payments and arguments with no record are created.

Why payments fall here specifically

Salary runs through an orderly process with a fixed date and a named owner. A non-salary payment does not: it arrives as a WhatsApp message with a photo of a receipt, is approved verbally, and is paid as a single transfer. There is no number, no status, and no place showing all open claims.

The predictable outcome is an employee asking two weeks later whether it was paid, and nobody able to answer without searching the bank statement. In the worse case they are asked again, paid again, and it surfaces - if at all - in the month-end reconciliation.

The identifier that solves most of it

The single step that changes the picture is giving every claim a number and requiring every payment to point at it. From there every other control opens up:

• You can ask "what is the status of claim 412" and get an answer.
• You cannot pay twice, because the number is already marked paid.
• You can produce a list of all open claims before payment day.
• The receipt is stored attached to the claim rather than in a message thread.
• You can tell who approved, and when.
• At year end there is a complete list rather than a search through transfers.

No dedicated system is needed for this. A form writing to a sheet, or a table in the system you already run, is enough - as long as the number exists and is actually used.

Controls by payment type

The fourth row is the one calling for care. Whether a given payment is a reimbursement or a payroll component is a question for the accountant, not one to settle in an internal procedure - so the correct operational rule is that any unclear payment is classified in advance, not in retrospect.

Separating approval from payment

The most effective control here costs nothing: whoever approves a claim is not whoever makes the payment. In a five-person business that sounds over-formal, and in practice it prevents the two common cases - a claim paid without being approved, and a claim approved twice by two managers in error.

Where there is nobody to separate to, the alternative is separation in time: claims are collected, reviewed as a list on a fixed day, and paid in one sequence. Reviewing as a list is what creates the catch - a duplicate is obvious in a ten-row table and invisible when each claim is handled on its own.

A company card against a reimbursement after the fact

Both exist at every business, usually without a decision. The operational difference is not the amount but when the control happens: with a company card it is before the purchase - who holds a card and what may be bought on it - and with a reimbursement it is afterwards, once the money is already spent.

So the simple logic is to move recurring, foreseeable spending onto a card and leave one-offs to reimbursement. A business doing the reverse - a card free for anything, reimbursements only when there is no choice - ends up with no control at all: the card is not pre-approved and the receipts are not checked after the fact.

What stays common to both is the receipt. A company card expense needs a receipt attached to the record too, or at month end there is a line on the card statement nobody can explain - and that detective work lands on whoever is already busiest.

What happens when an employee leaves with an open claim

This is where the absence of a central record costs most. An employee who has left with an unpaid reimbursement will get in touch a month later, and by then there is nobody to ask - the manager who approved may not remember, and the claim itself was a message since deleted.

The procedure that prevents it is one check of the open claims list at the end of employment, before the final payment: what is open in that person's name, what is approved, and what was declined and why. The same check works in the other direction too - an advance not yet offset, or equipment recorded as a purchase on the company's behalf.

It is a five-minute check that requires only that the list exists, which is exactly why the identifier from the earlier section pays for itself even at a business where this happens once a year.

Changing an employee's bank details

This is the same fraud vector familiar from suppliers, and it is more dangerous because a message from an employee looks internal and is therefore checked less. The procedure is identical: a change of bank details is not verified on the channel it arrived through.

Beyond that there is a personal data dimension here. Employees' account details are information kept over time, so they belong to the mapping described in digital employee records - who may see them, where they are held, and what happens when somebody leaves.

When do you pay?

The simple answer is one fixed date a month rather than "whenever a claim arrives". That sounds harsh on the employee and is precisely the opposite: a known date is an answer to "when will I get it", and that beats "soon" even when it is further away.

What is required alongside it is a defined exception - a large expense an employee funded personally should not wait three weeks. The operational rule is that the exception exists, is written down, and passes through the same record, rather than being decided afresh each time. The same logic runs in a weekly supplier payment run.

Sources

• Israel Tax Authority - online services for businesses
• A weekly supplier payment run
• Digital employee records
• Book a call