Reconcile IT workforce and learning records across delivery locations

An employee completes a course while based in Bengaluru, then transfers to Pune. If the reporting team joins the learning export to the latest HR file, those earlier hours move to Pune too. The company total can still balance. Reconcile the effective dates behind the location totals before accepting that agreement as evidence of a correct result.

This article is for IT services HR, learning operations, delivery managers and reporting coordinators. Its original fictional case produces two separate outputs: a closing workforce view and a June learning ledger attributed to the delivery base at completion. It is an internal reconciliation exercise, not a statutory disclosure, a training-effectiveness assessment or a client staffing approval.

Decide which location each output describes

The fictional company has one employing entity and two administrative delivery bases, Bengaluru and Pune. A client project, the place someone happens to work and their approved delivery base are separate fields. An employee visiting a London client remains assigned to Bengaluru in this exercise. Working remotely also leaves the approved base unchanged unless HR records an effective transfer.

The owner fixes June 2026 as the learning period and the end of 30 June as the workforce snapshot. Both use Asia/Kolkata time. HR confirms the employment population and effective dates; learning operations confirms completion states, course versions and credited durations. These are case assumptions. A real assignment must use its own approved definitions, access permissions and reporting requirements.

Keep employment history, delivery-base history and learning events as separate records. The authorised HR custodian supplies a stable person reference and approved links from learning accounts. The reporting file needs the reference and decision evidence, rather than names or a new collection of identity documents. A current email address alone is a weak basis for reconstructing historical accounts.

Establish the workforce view before joining learning

All eight employee references below are invented. E01, E05 and E06 have Bengaluru as their base throughout June. E07 and E08 have Pune throughout. E02 moves from Bengaluru to Pune at the start of 16 June. E03 remains in Pune until employment ends after 20 June. E04 joins in Pune at the start of 10 June. No other employment or base changes occur in this case.

The closing employee set is E01, E02, E04, E05, E06, E07 and E08. Bengaluru therefore has three people and Pune four, giving seven at month-end. Eight different employees were employed at some point during June. Keep both sets: a valid learning completion by E03 before departure can belong to June even though E03 is absent from the closing set.

For its separate capacity view, the fictional company uses contracted weekly hours divided by its 40-hour full-time week. E06 has 20 hours; every other closing employee has 40. The closing result is 6.5 FTE, comprising 2.5 in Bengaluru and 4 in Pune. These are stipulated case definitions, not a recommendation for every workforce measure.

The Office for National Statistics' June 2026 public-sector employment bulletin distinguishes headcount from FTE and identifies differences between providers using contracted hours and those using actual hours. This is a narrow example of why the measurement basis matters. The UK public-sector methodology does not set this IT company's reporting rules.

E05 also appears on two client plans, allocated 60% to one account and 40% to another. Those rows describe planned deployment of the same employee. They do not add two people to the HR roster. Keep client allocation percentages in their own schedule; they are neither employment hours nor a rule for splitting that employee's learning between delivery bases.

Read the event ledger on its own terms

The selected learning export contains twelve rows. In this exercise, credited hours are the approved course values attached to completed attempts, not measured attendance time. Different attempts may earn separate credit under the stated policy. Learning operations confirms that the seven accepted rows below are valid completions, that their credits are permitted and that none has been withdrawn. The account-to-person links are already checked.

L01 records E01 completing a data-handling module on 5 June for 2 credited hours. L02 records E02 completing a cloud module on 12 June for 3 hours. L03 records E02 completing a different module on 24 June for 1 hour. L01 and L02 belong to Bengaluru; L03 belongs to Pune because the transfer has taken effect.

L04 records E03 completing a module in Pune on 12 June for 2 hours, before departure. L05 records E04 completing a module in Pune on 18 June for 2 hours, after joining. L06 records E05 completing Secure deployment version 2 on 20 June for 4 hours. L07 records E06 completing a module on 25 June for 1.5 hours. L06 and L07 belong to Bengaluru.

The reporting join asks two questions of each accepted event: was this person an included employee when it occurred, and which base was effective then? For E02, use Bengaluru before 16 June and Pune from that date. Do not join each event to every historical base row and then sum the expanded result. Each accepted event must have exactly one valid employment match and one base match under this case's rules.

Write the interval convention into the handover. Here, the old base interval ends immediately before the new one begins. If an event falls in a gap, or two histories both cover it, send that event to the exception list. An arbitrary first match would conceal the missing or conflicting history. Keep the original event and the specific HR decision needed to resolve it.

Give the five remaining rows different dispositions

L08 belongs to E07 and carries the timestamp 30 June 2026 at 18:40 UTC. That is 1 July at 00:10 in Asia/Kolkata. Its 1 credited hour belongs outside this June ledger. Preserve the original timestamp and the reporting-zone conversion. A June date in one export column is insufficient when the agreed boundary uses another zone.

L09 reports a 2-hour completion on 26 June under an account that the authorised custodian has not linked to a person. Leave it unresolved. It might belong to an included employee, a contractor or someone outside the selected entity. The coordinator cannot infer E08 merely because E08 has no accepted completion in this extract. This unresolved row means the accepted learning result is provisional.

L10 repeats L01 after a file re-import. Learning operations confirms the same provider, account, course version and attempt identifier, with matching completion time and credit. Retain both raw rows and count the confirmed attempt once. Matching person and course alone would be insufficient: a genuine later attempt could share those two fields.

L11 is a confirmed 2-hour completion by contractor C01. Preserve it in the separate contractor-learning schedule; this particular employee ledger excludes it. L12 is E05's assignment to Secure deployment version 3, with 4 catalogue hours. Its status is assigned, with no completed attempt. It contributes no credited hours to this completion ledger. A catalogue duration is not evidence of completion.

The row disposition reconciles exactly: seven accepted employee completions, one event outside the period, one unresolved account, one duplicate import, one contractor completion and one incomplete assignment make twelve. This row bridge explains processing. It is not a training participation rate or an assessment of how much learning the workforce needs.

Test a result that balances but is wrong

The accepted Bengaluru credits are 2 + 3 + 4 + 1.5 = 10.5 hours. Pune has 1 + 2 + 2 = 5 hours. Together they give 15.5 credited hours across seven completed attempts by six distinct employees. E02 appears twice because two different modules were completed. These are selected, resolved records; L09 is still open.

Now deliberately replace each event's historical base with that person's latest known base, while retaining E03's last base after departure. E02's 3 earlier hours move from Bengaluru to Pune. The incorrect location results become 7.5 and 8, yet still total 15.5. A group-total check cannot detect this attribution error. Compare the event-to-base decisions as well as the arithmetic.

A second faulty method joins only to the closing employee set. It also drops E03's valid 2-hour completion. Combined with the latest-base error, it gives Bengaluru 7.5 and Pune 6, totalling 13.5. The missing 2 hours are not a learning adjustment; they result from applying a closing workforce population to events earlier in the month.

Reverse the test for E04: a supposed completion before the 10 June employment start would need review, even if the person is present at month-end. The same identity may legitimately exist in a pre-employment portal. Its inclusion in an employee-learning measure needs an explicit decision, rather than automatic acceptance because the latest HR row exists.

Original fictional case. The same 15.5-hour total can conceal a three-hour location error. The accepted ledger remains provisional because L09 has no confirmed account-to-person link.

Keep delivery readiness separate from monthly credits

The fictional client plan requires Secure deployment version 3 for E05's July assignment. L06 supports the June credit for version 2; L12 shows only a version 3 assignment. Neither closes the stated version 3 completion question. The delivery manager needs the required version, accepted completion evidence and any additional client checks before deciding readiness. The June ledger cannot make that decision for them.

Do not turn 15.5 divided by seven into an average-hours claim here. Seven describes the closing roster; the accepted credits include a leaver, exclude an unresolved account and use course credits rather than observed attendance. If management needs an average or coverage measure, commission the matching population and duration policy explicitly. The purpose of this exercise is to reconcile the histories feeding those later measures.

Hand over the exceptions with the reconciled schedules

The handover contains the seven-person closing roster, its separate 6.5 FTE capacity view, the event-level base attribution and all twelve row dispositions. Keep the extraction dates, approved account links, history versions, time-zone rule and credit policy together. A later extraction can change what the team knows about June without changing when the underlying learning occurred.

Assign L09 to the HR account custodian and learning owner. If its identity and eligibility are confirmed, update its disposition and both location totals through a recorded revision; do not quietly replace the provisional file. Keep the unresolved version available so a reviewer can explain the movement. A later correction to E02's transfer date likewise requires reconsidering affected events, even when the company total stays unchanged.

For a review, ask someone to trace L02 to the pre-transfer Bengaluru interval, retain L04 despite the departure, and convert L08 across the month boundary. These three checks expose different weaknesses that a balanced total can hide. The reporting coordinator should be able to show the supporting record for each decision without circulating personal employee files.

Discuss an IT reporting request with Nitium Advisory using a non-confidential outline of the intended output, delivery locations and record gaps. Keep employee-level files with the approved custodians during the initial enquiry.

Source checked 14 October 2026: Office for National Statistics, Public sector employment, UK: June 2026, section 4. Contains public sector information licensed under the Open Government Licence v3.0. All company records, identifiers, course names and calculations in this article are original fictional teaching material.