How to Define Who Can See Financials in a Language School
How to set up access permissions in a language school so each teacher or staff member only sees what they need, keeping financial data protected.
When a language school has just one teacher, there is not much to worry about: everything stays in one account, and no one else needs access. But as soon as the team grows, whether that means a second teacher, an administrative assistant, or someone handling sales, the question naturally comes up: who can see what?
Setting up financial access in a language school is a problem most owners solve too late, usually after some awkward situation. A teacher who saw a revenue report without needing to. A new employee with access to everything because "it was easier that way." A shared account that a staff member took with them when they left.
Why this becomes a problem early
The financials of a language school involve data that tends to be restricted even in larger companies: who owes money, who paid, which student is on which plan, how much each service generates in revenue, what the month's turnover looks like.
A teacher who gives classes does not need to know the school's total revenue. They need to see their own students, their scheduled classes, and maybe log a sale when they sell a package. But they do not need to see the cash register, the revenue report by service, or the overdue installments of students who are not even theirs.
This separation seems obvious when you say it out loud, but it only exists if the system you use allows you to configure it. Most systems that language schools use today do not allow this.
What happens when there is no access control
The most common alternative is improvisation. One school uses a shared spreadsheet and simply "trusts" that teachers will not open the financial tabs. Another uses a system with only two access levels: "admin" (sees everything) or "user" (sees almost nothing), with no middle ground.
When the system has no granularity, the school owner ends up stuck between two bad choices: give too much access or give too little. Giving too much exposes sensitive data. Giving too little means doing everything manually, because the teacher cannot even log a sale without asking for help.
Another common problem is the single shared account. Some smaller systems do not support multiple users with separate passwords, so the school ends up with one account that everyone uses. When someone leaves, you change everyone's password. The history of who did what disappears.
What good access control needs to do
For a language school to function with a team, access control needs at least three things:
Individual users with separate passwords. Each teacher and staff member logs in with their own credentials. When someone leaves, you deactivate that person's access without affecting anyone else.
Module-level permissions. The system must allow you to configure what each person can do in each area. Schedule is one area. Students is another. Financials is another. Reports is another. Each of these areas can have read-only permission, edit permission, or no permission at all.
Reusable roles. When you have several teachers with the same access profile, you need to create a role, such as "Teacher" or "Coordinator," and apply it to all of them. It makes no sense to configure permissions one by one for each person every time someone new joins.
Without this, you will either expose data you should not, or create a bottleneck where everything depends on you.
What the usual alternatives offer
Most tools that language schools use today were not built for this scenario. Google Workspace allows you to share documents and spreadsheets, but controlling who can see which tab in a spreadsheet is manual, fragile, and does not scale. A teacher with access to Drive has access to everything in that folder, unless you build a very careful folder structure.
Generic management systems, such as ERPs or CRMs not specialized in education, often have more developed access profiles, but they do not understand the logic of a language school. You end up adapting the system to your workflow instead of the system supporting it.
Marketplace tools for teachers, such as Cambly or Preply, do not have this problem because the teacher is an individual service provider with no view of the business as a whole. But when you run your own school, with your own team, you need something different.
How Noladi solves this
Noladi lets you create custom access roles for each team profile in the school. You define the role name and choose, module by module, which permissions that role has.
A "Teacher" role can have access to view and create classes, view and edit their own students, but no access to billing reports, no access to the cash register, and no access to other students' installment records. A "Financial Coordinator" role can have access to reports, receivables, and sale logging, but no access to create or edit classes.
You create the role once and assign it to as many staff members as you need. When a new person joins, you invite them by email and apply the role. When someone leaves, you deactivate their access individually, without affecting anyone else.
Permissions are grouped by module in the interface: Students, Appointments, Rooms, Financials, Reports, Team. You can clearly see what each role can or cannot do before saving.
This structure avoids the two extremes that hold most schools back: the teacher does not see what they do not need to see, and the owner does not have to do everything alone because the system would not let anyone else do anything.
Get to know Noladi
If you want to organize your language school team's access without exposing financial data to those who do not need it, Noladi was built for exactly that. Create your account at https://noladi.app/teacher and see how it works in practice.