The DA DIFFERENCE Field Tells You More Than the Payslip Does
There is a field in this template called DA DIFFERENCE. Most payroll systems do not expose it directly — they absorb it into the gross figure and move on. That silence is where discrepancies breed. Dearness allowance revisions under the 7th Pay Commission do not always land cleanly. A January revision might not be reflected in the February payslip. The arrears hit in March. If you are not tracking the DA DIFFERENCE as a discrete integer each month, you cannot reconcile what was promised against what was paid when the arrear disbursement finally comes through.
This template treats the Gujarat government salary structure as it actually is: a multi-component system where the gross is an output, not an input.
What the Computed Fields Actually Do
The GROSS AMOUNT field is a JavaScript-calculated field that sums BASIC + DP + DA + HRA + MEDICAL + WASHING + CLA + TRANSPORT + DA DIFFERENCE + ARREARS + LTC + 7TH PAY HRA. Not an estimate. Not a static entry. A live computation that updates the moment any input field changes. If the DA rate is revised from 42% to 46% in April, you update the DA RATE field, and every record for that month recalculates instantly.
DA itself is a calc field: (BASIC + DP) × DA RATE / 100. The distinction between BASIC and DP matters here — Dearness Pay is a legacy component that persists in older pay scales and does not exist in all employees' records. The formula accommodates both. If DP is zero, it drops out cleanly.
The 7TH PAY HRA calc field — BASIC × (NEW HRA RATE / 100) — reflects the separate HRA calculation methodology introduced under the 7th Pay Commission, where HRA is computed as a percentage of basic pay rather than a fixed allowance. Running both HRA (legacy fixed amount) and 7TH PAY HRA (percentage-based) in the same record lets you track the transition period without losing historical accuracy.
NET SALARY is calculated as GROSS AMOUNT minus DED, where DED is a separate JavaScript field summing GPF + P TAX + SIS + I TAX + MISC REC. The use of both a CALC field (DEDUCTION) and a JS field (DED) for the same deduction logic is intentional — the JS field feeds the net salary computation at the display layer, while the CALC field provides a readable breakdown in reports.
What April Looks Like After Twelve Months of Entries
After a full financial year of monthly entries — each tagged with MONTH date and FINANCIAL YEAR text — the database becomes an audit trail. Filter by FINANCIAL YEAR "2023-24" and you have all twelve months of a specific employee's compensation history, with every component broken out.
GROSS GPF — calculated as GPF + GPF INT minus GPF UPAD — gives you the net provident fund position each month. GPF interest is credited annually, but tracking it monthly means you catch any entry error before year-end reconciliation. If January shows GPF INT jumping unexpectedly, you know immediately rather than discovering it when the GPF passbook is updated.
The GPF NO field stores the employee's provident fund account number as a single-line text identifier. When cross-referencing against the Treasury or PAO records during audit, that number is the anchor.
The REMARK field exists for the edge cases: a month where LTC was disbursed, a month where MISC REC reflects a salary recovery, a period where the DA revision was applied retroactively. The structured fields carry the numbers. REMARK carries the context that makes the numbers defensible.
At the end of a financial year, sorted by MONTH, GROSS AMOUNT trending upward by DA revision increments while DEDUCTIONS track predictably against salary slab — that is a clean payroll record. Any deviation from that pattern is visible immediately.