Client transfers between branches in Fineract

When a branch reorganization means transferring clients in Fineract

A merger, a branch closure or a regional redesign often means moving clients and their accounts from one office to another. In Apache Fineract, this is handled as a propose and accept transfer: a user proposes moving a client to a destination office, and a user at the destination accepts it. Teams need this flow when the client relationship, loan history and savings balances should carry over unchanged, because closing the client and onboarding them again would end existing accounts, repeat KYC and break the continuity of the record. Re-onboarding is the simpler choice only when the client's identity or eligibility must be re-verified anyway, or when the destination branch will run different products and the organization wants a clean start. In scope for the transfer are the client record, the client's loan and savings accounts, the loan officer assignments tied to those accounts, and any group or center membership the client holds. The feature moves the record and its linked data, but it does not decide the business questions around the move. Your organization still has to decide which officers take over each portfolio, whether group memberships should follow the client or be dissolved, whether the destination office offers the same products and charges, and how staff in each branch are notified and trained. Those decisions belong in the reorganization plan before any transfer is proposed.

Exact behavior varies by release, including which linked entities move automatically, what validation runs on acceptance, and whether a pending proposal can be withdrawn. Confirm each of these against the Apache Fineract platform documentation for the release you run, and test them in a non-production tenant that mirrors your office tree and product catalogue. Pay particular attention to the Fineract-Platform-TenantId header used in each call, because a reorganization spanning several tenants needs its own mapping. Before a branch reorganization, check the accounting effects with your finance team. Transfers can change which office a loan or savings account reports against, which affects branch-level closures, accruals and reports. Run a test transfer, close a test accounting period, and compare the resulting entries with the source and destination offices before you move production data. Ask the implementation partner to document the proposal, acceptance and rollback steps as part of the written scope.

Transfer options and when each fits

This table compares the four main ways a branch reorganization can move clients, plus two edge cases that often appear in practice. Read each row for the trigger, what moves, what must be settled first and the risk that most often causes trouble. The main takeaway is that the option should follow the client's loan and group position, not the org chart alone.

Option	Trigger	What moves and what settles first	Main risk
Whole-client transfer with accounts	Client relocates or the client's office is consolidated into another branch	Client record, open loans and savings move. Settle pending approvals, due collections and open cash for the day first.	Loans and savings split across two offices in reports until the move is complete everywhere
Officer reassignment only	Loan officer leaves or caseloads are rebalanced within the same office	Assigned officer changes on clients, groups and accounts. Settle open collection sheets and overdue follow-ups with the outgoing officer.	Overdue loans lose follow-up while ownership is unclear, and officer-level reports shift mid-period
Group-level move for field lending	Center or group moves to another branch's meeting schedule or is merged	Center, members, meeting calendar, group roles and group loans move together. Settle group collections and agree roles in the target office first.	One member is missed, so the group is split across offices and group loan handling breaks
Keep clients at source until loans close	Client is moving, but loans run past the reorganization date	Client stays at the source office. Agree who collects, when loans close and which new products open only at the target.	Client appears in two offices and new business is opened under the wrong office
Permanent branch closure	Branch closes and its portfolio has no remaining owner office	Portfolio is reassigned client by client. Stop new disbursements and complete office-level closures before the final move.	Clients without an active owner are missed in collections and follow-up
Transfer inside an open accounting period	Reorganization date falls within a period that is still open	Confirm with your version how entries posted before the move report by office, and reconcile each office before the move.	Branch income and closure reports may misstate results for the period

How to run a client transfer from propose to accept

This sequence moves a client and their accounts from one office to another with a documented proposal, a receiving-branch review and an acceptance that leaves a clear audit trail. Each step closes with a check so the branch reorganization can be reconciled before the old office stops working the client.

Confirm the target office and hierarchy
The operator with administrator rights confirms that the destination office exists in the office tree, sits under the correct parent, and has its loan officers and staff set up before any client moves. Record the destination office ID from the office list in the transfer ticket. The step is done when the office appears in the hierarchy view under the intended region and the receiving branch lead confirms in writing that the branch can take the client.
Settle open transactions and set a cut-off
The source branch completes pending repayments, savings deposits, withdrawals and any collection sheets that include the client, then agrees a cut-off date with the receiving branch. Confirm the business date and check that no unposted transactions remain on the client's loans and savings accounts after the cut-off. The step is done when the account statements for the period before the cut-off reconcile to the cash collected and the cut-off date is written into the transfer record.
Propose the transfer from the source office
A user at the source office submits a transfer proposal that names the client and the destination office, using the propose transfer action on the client record in Fineract. The proposal sits pending and does not change the client's office. If your deployment has maker-checker approvals enabled for this action, a second user must approve the proposal before it takes effect. The step is done when the client shows a pending transfer and the proposal ID is recorded.
Review the proposal with the receiving branch
A receiving-branch user reviews the pending proposal alongside the source branch, listing the client's loans, savings accounts, groups and assigned loan officer. The review decides which accounts move, which officer takes them over and whether the client should join a destination center or group. Any mismatch is resolved before acceptance, and the decision is recorded by a second person who was not part of the proposal. The step is done when both branches sign off the list.
Accept the transfer at the receiving office
A user at the receiving office accepts the pending transfer. Use a different user from the one who proposed it, so the proposer and the acceptor form the two-person control your procedure expects. Acceptance is the point where the client's office changes in Fineract, so run it only after the review is signed off. The step is done when the transfer no longer shows as pending, the client's office reads as the destination, and the acceptance is logged against the acceptor's user account.
Verify accounts, officers and accounting effects
The receiving branch checks that each loan and savings account now shows the destination office and the newly assigned loan officer, and that no account was left with the source office or an inactive officer. Accounting staff review journal entries and office-level postings dated around the transfer, comparing them with the source and destination ledgers and any branch closures. Confirm this with Fineract's accounting reports for your release. The step is done when a second reviewer signs off the account list and the ledger check.
Verify group membership and field schedules
The operator confirms that the client has been removed from the source center or group and added to the destination group if the review required it, and that the meeting calendar for the destination group includes the client. Check that collection sheets for the next meeting day list the client under the correct officer and office. The step is done when the group rosters for both branches match the agreed list and a reconciliation note is filed with the transfer record. Before running this in production, confirm the exact endpoints, required permissions and transfer behavior for your release in the Fineract documentation, and test the flow in a non-production tenant.

Accounting effects to check before a branch reorganization

Before any client moves between offices, the team needs to confirm what the general ledger will do with that movement. The first thing to verify is the accounting state of both offices at the moment the transfer is accepted: whether each office has an open accounting period, whether any office-level closure is pending, and which accounting mode each office is configured to use. Fineract's accounting closures and office-level settings are the controls to inspect, and the answers should be written down by finance before the reorganization date is fixed. If either office is closed for the period in which the transfer will be accepted, the team should plan the timing of the accept step around that closure rather than assume the system will handle it.

Second, the team must establish how balances and accrued interest attach to the loan and savings accounts being moved. Ask finance to list, for every account in scope, the outstanding principal, unpaid charges, accrued but unposted interest and any held or blocked amounts, and to record which GL accounts those balances sit in today. Then compare that list with the balances after the transfer is accepted. Confirm in your own environment, with the vendor documentation and a test run, whether accrued interest moves with the account and posts under the receiving office, and whether any postings are made at the time of transfer or at the next end-of-day process. Do not assume the answer from the product name or from another deployment.

Third, cross-office postings must reconcile to the external ERP. Any entry that touches a GL account used by both offices, or that records a balance change tied to the receiving office, needs a matching entry in the ERP ledger that the finance team can trace. Build a reconciliation that starts from a trial balance per office before the transfer, applies the expected movements, and ends at a trial balance per office afterward, then compares the totals with the ERP. Test this on a copy of production data, not on a development dataset, and keep the test output as the evidence for sign-off. Finance should approve the reconciliation in writing before the production reorganization is scheduled, and the sign-off should name the accounting periods covered.

What changes for loan officers and groups during a transfer

Moving a client between offices touches more than the client record. Loan officers, group and center membership, meeting calendars, staff access and reports all depend on the office a client sits in, so each one needs an explicit decision before the transfer is accepted.

Reassigning loan officers on clients and loans

Decide whether each client's loan officer moves to someone in the receiving office, and whether open loans keep their current officer. In Fineract the officer is set separately on the client and on each loan and savings account, so a transfer that updates one may leave the other pointing at a staff member who no longer covers that branch. Check the client record, every active loan and every active savings account for the officer field before closing the change.

Group and center membership

Decide whether a transferred client leaves the group and center they belong to, or whether the whole group moves with them. A client removed from a group at the old office can leave a loan with group-level terms orphaned, while a group moved as a unit can pull members who live near the old branch. Check group membership, center assignment and any group-linked loans after the move.

Clients whose group stays behind

When a client moves but the rest of the group stays at the original office, the group's meetings, collections and loan schedules still run where the other members are. Decide whether to split the client into a new group at the receiving office, keep the membership across offices, or hold the transfer until the group is reorganized. Confirm the approach with your lending policy before the transfer request is submitted.

Meeting calendar for the receiving office

Transferred clients and groups need meeting schedules that exist in the receiving office. Check that centers and groups have calendars at the new branch, that meeting days do not clash with existing collection sheets, and that field officers can see the upcoming meetings. A client who arrives without a valid meeting slot can miss collections on their first week in the new branch.

Staff user access after the move

Staff access in Fineract is scoped by office, so a loan officer who moves branches may keep access to the old office's data or lose access to clients they still serve. Decide which staff members change offices, update their office assignment and roles, and confirm that they can see the transferred clients and no more. Test access with a non-administrative user before the move goes live.

Reports that filter by office or officer

Portfolio, collection and arrears reports often filter by office or loan officer, so a transfer changes historical and current totals in ways that can confuse reviewers. Decide whether reports should show clients under their current office or the office where the loan was originated, and document the rule. Run a before and after comparison of the portfolio by office and by officer to confirm that totals reconcile.

How to sequence transfers by reorganization size

A single client or a small batch is the lowest-risk move because it touches a limited set of accounts and one officer assignment. Sequence it as a proposal from the source branch, a review of every open balance, an acceptance at the receiving branch, and then a comparison of schedules and postings against a snapshot taken before the move. Keep the batch small enough that one reviewer can check every account.

Freeze the window: Agree a cut-off with branch staff so no repayments, disbursements or savings transactions post to the source branch between the proposal and the acceptance.
Check every open account: Review each loan, savings and deposit account, along with guarantees and pending applications, before proposing the move.
Confirm the receiving officer: Decide who will own the client at the receiving branch and confirm that person exists with the right permissions.
Plan the rollback path: Confirm whether your version supports a clean reverse transfer or whether a documented correction is needed, and record the snapshot used to verify it.

Confirm how a pending proposal behaves if the receiving branch rejects it or the source branch needs to withdraw it.

Security and operational controls for transfers

Restrict who can propose and who can accept a client transfer. Treat the transfer as two separate duties: the person who proposes a move between offices should not also be the person who accepts it on the receiving side. Map these to Fineract roles and permissions in your own configuration, so that the propose and accept permissions sit with different users, and review which staff hold the broader office, client and staff permissions that let them reach the same records by another route. Confirm in the deployed release whether approval steps for client transfers are configured and enforced as you expect, and test the separation with two non-administrative test users before go-live. Record the named owners of each permission set, since a branch reorganization often shifts who holds these rights for a few weeks.

Scope what the receiving branch can see before the first transfer. Office hierarchy determines what users see in Fineract, so a receiving branch user should be able to view and act on the clients being transferred to them without gaining visibility of unrelated clients, loans or savings in the source office. Test this with a user assigned to the receiving office, checking client lists, loan lists, reports and collection screens for records from other offices. Confirm what audit records Fineract writes for each proposal, acceptance and rejection, including the user, timestamp and before and after office and loan officer values, and decide where those records are retained and who may export them. Ask your implementation partner or the project documentation to confirm the audit coverage in your release, because the trail for transfers is only useful if it can answer who moved which client, when and on whose approval.

Plan the batch around the close of business day job. Schedule transfers in a defined window agreed with branch operations, and avoid running them while the Close of Business Day job is active, since the Apache Fineract platform documentation describes the job as a scheduled process that can run for several hours on large deployments. Take a database backup immediately before the batch, verify it restores, and record the backup identifier in the change ticket. Run a small pilot set of transfers first, reconcile client counts, active loans and savings balances by office, and only then proceed to the full list. Keep a rollback decision point agreed in advance, so that any discrepancy found during reconciliation stops the batch before further offices are affected.

Limits to confirm in your Fineract environment

A branch transfer touches loans, groups, reports, custom data and code at once, so the behavior of each piece has to be confirmed in your own release before the reorganization plan is fixed. The cards below list the points to test and how to test them.

Arrears and pending approvals

Confirm whether a transfer request is accepted for clients with overdue loans or with transactions still waiting for approval. Your branch reorganization plan should not assume the transfer succeeds for these clients until you have seen it work on a copy of your data. Test one client in each state, then record which office owns the overdue balance and the pending item afterward.

Group membership after transfer

Check whether moving a client who belongs to a group also moves the other group members, or whether each member must be transferred separately. Group meeting calendars, group loan ownership and group loan officer assignments can change differently from individual clients. Test a group with a shared loan and confirm the result before you schedule the move in bulk.

Historical reports and prior office

Confirm how reports run for past periods show the office a client belonged to before the transfer. Portfolio, collections and disbursement reports may attribute history to the new branch, which affects branch performance reviews and audit trails. Run the standard reports for a period before and after a test transfer and compare the office column for the same client.

Custom data tables

Verify whether entity data tables attached to the client, such as KYC or business fields, remain linked and readable after the transfer. Data tables scoped to an office or product may behave differently from those scoped to the client alone. Create a test data table entry, transfer the client, and confirm the entry is still visible and editable from the new office.

Release and end-of-life status

Confirm which Fineract release your environment runs and whether that release is still supported under the project's release policy before you change how branches are structured. Releases are created quarterly, and end-of-life releases are archived. Ask your platform team for the exact version in production and check it against the current stable release listed on the project website.

Custom code reading the office field

Identify any integration, report, custom module or scheduled job that reads the client's office identifier, because it may store the old value or assume a fixed office. Changes to the office field during a transfer can silently break these consumers. Search your custom code and integration configuration for office references and retest each consumer against a transferred test client.

Transferring clients between branches in Fineract: common questions

How much effort does a branch reorganization in Fineract usually take?

Effort depends mainly on how many clients, loans, savings accounts and groups move, and how many of those carry open balances or schedules that need checking. A reorganization that moves a handful of clients between two offices is a small exercise. One that moves a whole region, with groups, centers and officers attached, adds mapping work, test runs and reconciliation at each step. No public effort figure exists for this work, so ask any partner for a breakdown by account count, group count and office count in your written scope, and confirm each assumption about open loans and savings before you agree on timing.

What drives the cost of moving clients between offices?

The main drivers are the number of clients and their open accounts, the number of groups and centers whose membership or meeting calendar changes, the number of offices involved, and how much reconciliation your finance team needs afterward. Each open loan or savings account needs checking for officer assignment, office-level accounting and pending transactions. Groups add work because membership, roles and meeting schedules must stay consistent. Ask for a quote that prices these items separately so you can see which ones your own staff could take on.

Can our own team run client transfers between branches in-house?

Yes, a team with Fineract administration skills and access to the Fineract REST APIs can run transfers in-house, provided it has a tested runbook and a rollback plan. The propose and accept flow is a set of API actions that must be run in the right order, and each step must be checked against the accounting entries it creates. Teams that have not run a reorganization before often underestimate the reconciliation and sign-off steps. Confirm the exact endpoints and behavior against the Fineract documentation for your release before you commit to a method.

What do we need from our finance and branch staff?

You need finance staff to confirm the chart of accounts and office-level accounting for both the source and target branches, and to sign off the reconciliation before and after the move. Branch staff must confirm which loan officers, groups and centers should move, which clients are in arrears, and which pending repayments or savings deposits must be settled first. Both groups should agree the cut-off point, because transactions posted during the move can change balances. Put these responsibilities in writing before work starts so approvals do not stall the schedule.

How long does preparation take, and what sets that timeline?

Preparation length depends on data volume, the number of sign-off cycles your organization requires, and how many test runs are needed in a non-production environment. Large volumes need longer extraction and checking, and each approval layer adds waiting time that the technical work does not control. No duration figure is supplied for this task, so ask for a timeline that separates preparation, test runs, the cut-over window and post-move reconciliation, with a named owner for each sign-off.

What should a quote for a branch reorganization include?

A useful quote lists the scope in writing: which offices, clients, groups, centers, loan officers and accounts are in and out of the move. It should state the deliverables, such as a transfer runbook, test evidence, reconciliation reports and a rollback plan, and name what the client must provide. It should also say what is one-time work and what recurs, and whether any post-move support is included. Ask the provider to state its assumptions about open loans, pending transactions and accounting closures, because changes to those assumptions usually change the price.

What accounting effects should we check before moving clients?

Check how transfers affect office-level accounting, pending journal entries, and any closures or holidays already set for the source and target offices. Confirm that the accounting entries created during the move land in the correct branch and that balances reconcile in both offices afterward. Also check that open loans and savings keep the correct officer and office references, since reporting and collections often depend on them. Review these points against the Fineract documentation for your release and test them in a non-production copy before the cut-over.

How DeployOpen scopes and delivers branch transfers in Fineract

DeployOpen approaches client transfers between branches as a controlled change to your Apache Fineract office structure, not a one-off data edit. We scope the propose and accept flow, the loan officer and group changes, and the accounting checks for your environment, then build, test and document the procedure before any live reorganization.

How we scope

Inventory the clients, open loans, savings accounts and groups that move between offices.
Map which staff, loan officers and approval roles must act on each proposed transfer.
Agree in writing which accounting effects are reviewed before and after the transfer.

How we build

Document the propose and accept steps as a runbook your branch staff can follow.
Test transfers in a non-production tenant that mirrors your office hierarchy and products.
Build reconciliation reports that compare client and account balances before and after each batch.

How we hand over

Deliver the tested runbook, validation checks and reconciliation outputs with the agreed scope.
Walk through the procedure with the operations and finance staff who will run the reorganization.
Record open items, such as accounting mappings to confirm with your finance team, in the handover.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.
Ongoing support for later reorganizations and Fineract upgrades is available as a retainer.
Support can cover re-running checks after configuration changes, scoped in the retainer agreement.

Transferring clients between branches in Apache Fineract