Reimbursements & Encashments

This guide covers the two claim types that an employee submits. For loans, salary advances, and fines, see Loan / Advanced Salary.

Reimbursements and encashments are now two separate screens in the Payroll sidebar. They were one screen before. They have different approval rules and, more important, the money moves in a different way.

---

Purpose

An employee is sometimes owed money that is not a standard salary component. An employee pays for an expense and needs the money back. An employee has unused leave days or bonus points and wants them as pay. This guide tells you how each claim is submitted, approved, and paid.

---

The Important Difference

	Reimbursements	Encashments
Sidebar screen	Payroll > Reimbursements	Payroll > Encashments
What is claimed	Money the employee already spent	Unused leave days or bonus points
Approval	A multi-step chain, built from the reporting line	One step, by a permission holder
How it is paid	Outside payroll, by bank transfer or petty cash	Through payroll, as an allowance on a payslip
Does it reach a payslip	No	Yes
Final status	paid, after somebody records the transfer	approved

Important: A reimbursement no longer creates a payroll allowance. Before this change, the system paid an approved reimbursement two times: one time by transfer, and one time again on the next payslip that contained the claim date. The payslip amount was not visible on the reimbursement screen. Only encashments create an allowance now.

---

Part 1: Reimbursements

A Request Contains Days

A reimbursement request is a header plus one or more claimed days. Each day has its own date, its own amount, and an optional receipt.

The system derives the header from the days:

• The request total is the exact sum of the day amounts.
• The request date is the earliest day date.

Do not type the total. The system calculates it.

Procedure: submit a request

1. Open Payroll > Reimbursements.
2. Select Create.
3. Give the request a title and a description.
4. Add one row for each day. Give each row a date and an amount.
5. Attach a receipt to a row if you have one. A receipt is optional.
6. Submit the request.

Rules the system applies

• Each day amount must be more than zero.
• A request must contain at least one day.
• Two days in one request cannot have the same date.
• One employee cannot claim the same date two times while an earlier claim for that date is requested, approved, or paid. A rejected day releases its date, so the employee can correct the claim and submit it again.

A submitted request cannot be changed

The header, the days, the amounts, the receipts, and the approval chain are all locked when you submit. There is no draft status.

Before the first approver makes a decision, you can delete the full request and submit a corrected one. After the first decision, the system keeps the request for the audit record. You cannot change it or delete it.

How the System Finds the Approvers

The system builds the approval chain when the employee submits, and then locks it. It uses two inputs: the reporting line, and the escalation tiers of the company.

Employee submits
      |
      v
STEP 1 - go up the reporting line
   start at the reporting manager of the employee
   go up until you find a person who holds "approve reimbursement"
      |
      +-- found a manager --------> that person is step 1
      |
      +-- nobody above, but the employee holds the permission
      |                            --> the employee is the terminal authority
      |
      +-- nobody above, and the employee does not hold it
                                   --> the company fallback group
      |
      v
STEPS 2 AND ABOVE - escalation tiers
   add each tier that the largest single day amount reaches,
   in tier order
      |
      v
   Chain locked

Step 1 always comes from the reporting line

The walk starts at the manager of the employee, not at the employee. Two results come from this:

• The system never selects the employee as their own step 1 while an eligible manager exists.
• A subordinate never approves a superior. The walk only goes up.

The walk selects only a manager in the same company as the employee. It stops after 50 levels, or when it sees the same person two times. This prevents a loop in the reporting-line data from stopping the system.

Important: The permission gives the capability to approve. The chain gives the scope. A person who holds approve_reimbursement cannot approve any request they want. They can approve only a request where they are the current step.

Escalation tiers add senior approvers

A tier has a minimum amount and a named approver. The system adds the approver of each tier that the claim reaches, above step 1. A tier approver does not need to be in the reporting line of the employee.

Caution: The system compares a tier amount against each day amount, not against the request total. Five days of 200,000 do not reach a tier of 500,000. One day of 1,000,000 does reach it. This is deliberate, because a per-day limit is normal for travel and per-diem costs. Set your tier amounts against the cost of one day.

Terminal authority

If the employee holds the approval permission and no person above them holds it, the employee is the terminal authority for step 1. The system records a completed step 1 for them and sets the flag is_self_approved.

Terminal authority does not remove the tiers. Each different tier approver still makes a decision. A large claim from a senior person still gets the second pair of eyes.

You can filter the list on is_self_approved. An auditor will ask for it.

Fallback routing

If the employee does not hold the permission and no person above them holds it, the reporting line is misconfigured. This is not a reason for self-approval.

Employee holds the permission	A person above holds it	Result
Yes	No	Terminal authority, then the tiers
No	No	The company fallback group
—	Yes	Normal step 1 from the reporting line

The system routes step 1 to the fallback approver group of the company of the employee, sets is_fallback_routed, and tells the administrators. The tiers still apply above it.

Caution: Fallback routing is a signal that the reporting line needs a correction. If you ignore it, the HR group slowly becomes the default approver for a large part of the company. Look at the fallback-routed requests each month.

The chain does not change after submit

If an approver rejects the day that caused a tier, the approver of that tier stays in the chain. The system does not calculate the chain again. This prevents a rejection from silently removing a senior approver.

How an Approver Decides

An approver decides each day, not the request as a whole. The approver can decide the days one at a time or together.

• Each decision creates one permanent record. A later approver cannot change or hide the decision of an earlier approver.
• A rejection needs a note. An approval does not.
• The request goes to the next step only after the current approver decides every day that survived the earlier steps.
• The next approver sees only the days with no rejection.
• If a step rejects every day that remains, the request becomes rejected immediately. The system does not use the later steps.

The list screen shows the position of each request as Step 2 of 3.

The status of a request

Condition	Status
A step remains, and at least one day survives	requested
Every step is complete, and at least one day survives	approved
No day survives	rejected
Somebody recorded the transfer	paid

requested to approved to paid is the usual sequence. rejected is final.

Payment

An approved reimbursement goes to a payment queue. The queue is on the Reimbursements screen, with the title Approved reimbursements awaiting payment.

1. Pay the employee by bank transfer or petty cash.
2. Open the payment queue.
3. Put the transfer reference in the Payment reference field.
4. Select Mark paid.

The system then sets the status to paid, stores who recorded the payment and when, and tells the employee and the HR group.

Rules:

• The payment amount is the sum of the approved days. You cannot change it.
• A payment reference is necessary.
• Only an approved request can become paid.
• To record a payment, a user needs the pay_reimbursement permission. This permission is different from the approval permission, so an approver cannot certify their own payment.
• If you send the command two times, the system keeps the first result. It does not pay two times and does not send a second notification.

The unpaid reminder

The system sends a reminder about approved and unpaid claims:

• One digest for each company, with all the unpaid claims and a total. It does not send one message for each claim.
• Every 5 hours, but only between 08:00 and 17:00, Monday to Friday. Public holidays are not excluded.
• After 3 business days, the reminder also goes to the HR group.

These values are fixed. They are not settings.

Configuration: Reimbursement Approvers

Open Settings > Payroll > Reimbursement Approvers.

The page has two parts:

1. Fallback approver group, for each company. This is the HR group that receives a claim when the reporting line has no approver. The same group receives the payment notifications.
2. Escalation tiers: the order, the minimum amount, and the approver.

Warning: Each company must have a fallback approver group before any employee of that company can submit a reimbursement. Without it, the system refuses the submission and shows a configuration error. The settings page names the companies that have none.

The system also validates these rules:

• The fallback group must contain at least one active employee of that company.
• A tier approver must be active and must belong to the company of the tier.
• A member of the fallback group cannot also be a named tier approver for the same company. That overlap would make one person sign two times, or would quietly remove a necessary authority.

Who Can See a Reimbursement

The system does not use the reporting line for access. It uses the chain. A tier approver and a fallback approver are frequently not the manager of the employee. A manager-based rule would hide the request from the person who must act on it.

Rule	Who it gives access to
The claimant	Their own requests
The chain	The current approver and each earlier approver
Payment	A user with the payment permission, in the company of the claimant
Permission	A user with the global reimbursement view permission

The action list shows the requests of the user plus the requests where the user is the current step. A step further along the chain is not yet actionable.

---

Part 2: Encashments

What an Encashment Is

An encashment changes something the employee already has into pay:

• Leave encashment (needs Leave) changes unused days of one leave type into pay. It can use the available days and the carry-forward days of that leave type. The system counts them separately.
• Bonus point encashment changes bonus points into pay.

The Encashments screen has one tab for each type.

Encashments Keep the Earlier Behaviour

The reimbursement changes do not apply to encashments:

• The system calculates the amount. Leave days multiply by the leave rate, and bonus points multiply by the bonus rate.
• One person approves. The approval needs the change_reimbursement permission. There is no chain, no tier, and no fallback group.
• Approval creates a one-time allowance for the employee. The employee receives the money on the next payslip that contains the claim date.
• There is no paid status, because the payslip pays the claim.

The balance test happens at approval, not at submission

The system tests the balance when the approver approves, not when the employee submits.

Caution: If the employee does not have sufficient leave days or bonus points, the approval does not complete. The system shows a message and puts the request back to requested. It does not reject the request. The approver can easily think the approval was successful. Look at the status of the request after you approve it.

If you reject a leave encashment that was approved, the system gives back the available days and the carry-forward days.

The rates are system-wide

The leave rate and the bonus rate come from Bonus Unit and Leave Unit on the general settings screen.

There is one rate for the full system. You cannot set a different rate for each company or for each employee.

---

What Each User Sees

Action	Employee	Reporting Manager	Approver in the chain	HR / Payroll Administrator
Submit a request for themselves	✅	✅	✅	✅
See their own requests	✅	✅	✅	✅
Submit for another employee	—	—	—	✅
Decide a reimbursement	—	Only if in the chain	✅ (their step)	Only if in the chain
Record a reimbursement payment	—	—	—	✅ (with pay_reimbursement)
Approve an encashment	—	—	—	✅
Configure approvers and tiers	—	—	—	✅

---

How Visibility Is Decided

1. Ownership. Each employee submits and sees their own requests.
2. Chain position, for reimbursements. The system gives access to the current approver and to each approver that already decided. A manager who is not in the chain gets no access.
3. Permissions. Payment needs pay_reimbursement. Encashment approval needs change_reimbursement. Configuration needs the reimbursement settings permissions.
4. Company. The system finds the approvers, the tiers, the fallback group, and the notification recipients from the company of the claimant, not from the company selected in the session.

---

Customization Options

• Fallback approver group, for each company. It is necessary.
• Escalation tiers: the order, the minimum amount, and the named approver, for each company.
• Encashment rates: the leave unit and the bonus unit, for the full system.
• The approval capability is a Django permission (payroll.approve_reimbursement), so you give it through a role or a group.

The reminder times and the escalation period are fixed. They are not settings.

---

Good to Know

• A reimbursement never reaches a payslip. If you look for a reimbursement on a payslip, you will not find it. Look at the payment queue and the payment reference instead. Encashment payouts do reach a payslip. See Payslips.
• An encashment payout is an allowance. The system hides it from the main Allowances list and shows it only on the record of that employee.
• The receipt is optional for each day. Some companies need a receipt for each claim. The system does not enforce that rule, so make it part of your approval procedure.
• A tier compares against one day, not the total. An employee can keep a large cost below a tier if they divide it across days. The block on duplicate dates and the per-day receipt make this more difficult, but they do not stop it.
• Look at the self-approved and fallback-routed requests. Both are correct paths, but a large number of either one shows a problem with your permissions or your reporting lines.
• A reimbursement decision is permanent. The system keeps every decision of every step. This is the audit record, and nobody can change it.

What's owed, made whole.