When a transfer order arrives mid-year, the first question most teachers ask is about attendance and salary. The second question — about the portal — usually comes later, often after something has already gone wrong. That sequencing is the root of most transfer-related record problems in the Bihar education system.
E-Shikshakosh does not simply pause your records when you leave one school and resume them at another. It runs a live remapping process across four distinct record types, each with its own timing window, its own responsible party, and its own failure point. A teacher who understands only one or two of these types — typically the attendance record — is already exposed to the others.
The Four Record Types That a Mid-Year Transfer Touches
Every teacher profile on E-Shikshakosh contains several data layers, but a transfer specifically intersects four of them: the attendance record, the service book, the payroll linkage, and the school mapping data. These are not the same thing — they operate on different modules, are managed by different roles, and have different correction mechanisms. Treating them as one unified “record” is how teachers end up with a clean attendance register and a held salary simultaneously.
Attendance records are the most visible layer. These are the daily presence entries generated through the E-Shikshakosh mobile app, tied to GPS-based geofencing against the school’s UDISE code. They are stored per-month under your Teacher ID with the school’s UDISE code as a tag — not as the primary key. This is why your past attendance does not disappear when you transfer; the old school’s UDISE remains as metadata, but your Teacher ID is the anchor.
The service book is a separate module entirely. It is the digital equivalent of your physical service register, containing appointment date, category (BPSC/Niyojit), pay band, increment history, and training completions. It lives in the Teacher Registration module and is editable only when its status is set to “Active” by an authorized HM or officer. When your school mapping changes, the service book does not automatically re-assign — it retains its last submission state until someone with appropriate access modifies it.
The payroll linkage is what most teachers conflate with the attendance record, but it is mechanically distinct. The Bihar Education Department’s salary processing draws from a separate payroll database that is populated by the E-Shikshakosh MIS through a scheduled data push, not in real time. Your attendance being correctly marked in the app does not automatically update your payroll entry — it does so only after the data is frozen, pushed to the district MIS, and processed within that month’s salary cycle.
The school mapping data is the infrastructure layer underneath all three records above. It is the formal association between your 12-digit Teacher ID and a specific school’s UDISE code in the BEPC backend. When this mapping is incorrect or unresolved — which is the defining condition of a mid-year transfer in progress — the other three record types all degrade in different ways.
What the System Does to Attendance Data During the Remapping Window
The UDISE mapping conflict is the most misunderstood technical event in a mid-year transfer. When a transfer order is processed and your Teacher ID begins its reassignment from School A’s UDISE to School B’s UDISE, there is a window — typically ranging from 24 hours to several days depending on district workload and the speed of HM actions — during which the system holds your Teacher ID in an ambiguous state.
In technical terms: the old school’s mapping is flagged as “pending release” but not yet cleared, and the new school’s mapping is registered as “pending activation” but not yet confirmed. Neither school’s UDISE is fully authoritative over your Teacher ID at this moment.
The attendance module reacts to this state by failing to resolve your geofence. The app knows your GPS location. It cannot determine which school’s coordinates to check you against because the backend has not confirmed which school you belong to. The result on the app screen is either a “School Not Mapped” error or a location mismatch rejection, even if you are physically standing at the new school’s premises.
The days that fall inside this window are not automatically treated as absences in a permanent sense. The payroll engine holds them in a queue state, waiting for a resolved mapping before posting them. However, if the mapping resolution is delayed past the monthly salary cutoff — usually the 25th of each month — those days fall into the next cycle’s processing queue. The salary for the transfer month does not disappear; it is deferred, which feels identical to being cut but is a different administrative problem with a different resolution path.
The correction for unresolved transition-day attendance is not the same as the correction for a marked-absent error. A regular absent-but-present dispute is resolved by the HM with a biometric confirmation. A transition-day attendance dispute requires a written declaration from both HMs — the releasing HM and the receiving HM — confirming your physical presence on the disputed dates, submitted through the district grievance channel.
The Service Book — What Gets Locked, What Stays Editable, and Who Controls It
Teachers consistently underestimate how much the service book matters during a transfer. It is the record that downstream processes — increments, pension eligibility, deputation calculations — draw from. A service book that is incomplete or in draft status when you transfer creates compounding problems that surface months or years later, not immediately.
When you are mapped to a new school, your service book does not transfer jurisdiction automatically. For a period after your new HM activates your Teacher ID in their dashboard, the service book exists in a state where the old school’s HM has lost effective access to edit it (because your active mapping is now the new school), but the new HM has not yet verified and assumed editorial control.
During this gap, the service book is technically readable by both parties but editable by neither without a specific authorization from the DEO. This is a designed safeguard — it prevents one school from retrospectively altering a transferred teacher’s records — but it means that if there were any incomplete entries at the old school (a training completion that was entered but not submitted, an increment that was entered in draft), those entries are now frozen in draft state and cannot be finalized by anyone without district-level intervention.
What you should do before leaving your old school: log into the Teacher Module and review every entry in your service book. An entry showing a pencil icon or “Draft” label has not been submitted to the system. Have your old HM submit these entries while they still have active jurisdiction — which is before the disenrollment action is processed. Once the disenrollment is done, the HM’s editing access is removed.
What you should do at the new school: on your first week, ask your new HM to open your Teacher ID profile on their school dashboard and verify that the service book entries from your old posting are visible, submitted, and show no validation errors. If any entries show a red flag or validation warning, report them to the Block Education Officer (BEO) immediately — because validation warnings at this stage grow into data integrity blocks that affect payroll verification.
How the Payroll Engine Sees Your Transfer Month
The E-Shikshakosh payroll engine does not process salary on a teacher-basis. It processes on a school-UDISE basis. This is the architectural reason why mid-year transfers create salary complexity that feels disproportionate to the simplicity of the event.
For a full month where you are posted entirely at one school, the salary calculation is straightforward: your Teacher ID’s attendance data is summed under one UDISE code, validated against the frozen MIS data, and a salary figure is generated. For the transfer month — where you have working days spread across two UDISE codes — the engine runs two partial calculations and combines them. This is the proportional salary calculation: days at School A under School A’s UDISE, days at School B under School B’s UDISE, totalled under your single Teacher ID.
This proportional calculation only works if both UDISE mappings are active, frozen, and pushed to the district MIS within the same monthly processing window. If School A’s data was frozen and pushed on time but School B’s activation was delayed — even by a few days — only the School A portion gets processed in that cycle. The School B portion enters the next cycle. The total salary you receive for the transfer month will reflect only the School A days. The remainder arrives the following month after School B’s data is processed.
This is not a salary deduction. It is a salary delay. The distinction matters because the resolution process is different. A salary deduction is contested through a correction request referencing specific absent-but-present days. A delayed partial payment requires you to confirm with your new HM that the current month’s data has been frozen and pushed, and that your Teacher ID is correctly included in the school’s monthly MIS submission.
The monthly MIS submission deadline is determined district by district, but typically falls between the 20th and 25th of each month. If your new school’s HM activates your Teacher ID on the 22nd and the district deadline is the 20th, your inclusion in that cycle is impossible regardless of what either of you does. The delay is built in. Knowing this in advance — and not interpreting it as a system error — saves a significant amount of unnecessary grievance filing.
When the School Mapping Data Is Simply Wrong
Some mid-year transfers involve data errors that go beyond what HMs can resolve. These occur when a teacher’s UDISE mapping is corrupted rather than merely delayed — when, for instance, the system shows the teacher as active at the old school after the disenrollment was confirmed, or when the new school’s activation shows a validation error due to a mismatch between the Teacher ID data and the school’s category eligibility.
UDISE mapping corruptions that cannot be resolved at the school level have a specific escalation path: the Block Education Officer (BEO) can initiate a data correction request in the district MIS, which triggers a manual review by the District Education Officer (DEO). The DEO has backend access to the BEPC’s Teacher Data Management system that neither HMs nor BEOs have — specifically, the ability to force-clear a stuck mapping and re-initiate the assignment process.
To initiate this path, you need three documents: your transfer order, your joining certificate from the new school, and a screenshot of the error or incorrect status on the portal (either from your own login or obtained from your HM). Submit these physically at the BEO office along with a written application describing the specific mapping discrepancy. The BEO will raise a forwarded request to the DEO’s MIS cell.
The DEO-level correction typically resolves within seven to fifteen working days. During this window, your attendance data at the new school continues to be recorded (even if geofencing errors occur, the HM can manually verify attendance in the school dashboard), and your salary for the affected period is placed in a review queue rather than processed as absent. When the mapping correction is applied, the queued salary data is reprocessed and released.
If the correction is not resolved within thirty days, the next escalation is the BEPC district coordinator. Their contact information is available through the district education office and the official E-Shikshakosh grievance portal under “Escalation” within an existing grievance ticket.
What Teachers Get Wrong About Record Ownership
The most persistent misconception about E-Shikshakosh records during a transfer is that teachers own and control them. You do not — not entirely. Different records are under the control of different roles in the system, and assuming you can fix something yourself often wastes time while the actual responsible party remains unaware that an action is required.
Your attendance data from the app is generated by you, but it is only posted and frozen by the HM. The HM controls when and whether it is submitted to the district MIS. If your HM at the old school is slow to freeze the final month’s data before your departure, the delay in your salary is their administrative failure — but you are the one experiencing the consequence.
Your service book is editable by the HM within a window of active jurisdiction, and by the DEO or Block Resource Center personnel when correction requires higher access. You can view it. You cannot submit, edit, or approve any entry in it yourself.
Your payroll linkage is owned entirely by the district MIS team. No amount of action by you, your HM, or the BEO directly changes what the payroll engine processes. The only path to the payroll data is through the MIS submission process — which is why timely HM actions, correct data freezing, and within-deadline school-level submissions matter more than anything a teacher can do from their own login.
Understanding record ownership tells you immediately who to contact when something is wrong. A geofencing error on your attendance app is a mapping issue — contact the new HM. A draft entry in the service book is an HM submission issue — contact the relevant HM. A salary shortfall after a transfer month is a MIS processing issue — confirm with the new HM that your data was included in the monthly submission, then escalate to the BEO if it was not.
The One Record That Never Resets
Your 12-digit Teacher ID is the single record on E-Shikshakosh that is permanent and never school-dependent. It is not reassigned. It is not retired when you transfer. It is not archived. It is the thread that connects every posting, every school mapping, every salary cycle, and every service book entry across your entire career in the Bihar education system.
Because of this, protecting your Teacher ID credentials — particularly the Aadhaar-linked mobile number registered to it — is more important than any individual record correction. If your registered mobile number is outdated and your OTP delivery fails during the transfer period, you lose access to your own dashboard at the exact moment when you most need to verify your records. Updating this number requires Aadhaar-linked verification, which means it cannot be done in an emergency. It must be done proactively, before a transfer or any major administrative event.
Everything else about your E-Shikshakosh records during a mid-year transfer is recoverable — with the right documentation, the right escalation path, and patience measured in days or weeks. Losing access to your Teacher ID credentials is the one problem with no fast resolution.
For questions about E-Shikshakosh portal access, attendance errors, or transfer-related salary issues, use the official grievance portal at eshikshakosh.bihar.gov.in or contact your district’s Block Education Officer.