1. Introduction to MikroTik RADIUS Billing Components
You already know RouterOS well. You can read an interface list, spot a misbehaving client and trace a connection problem without much fuss. The part that trips up many small ISP operators is the billing layer, where a customer pays money and expects the right access in return. Users, profiles, payments and usage records all live in different places, and when they drift apart, you end up arguing with customers about what they bought and what they used.
This article gives you a clear mental model of how MikroTik RADIUS billing works, without any configuration detail. Think of it as one connected loop. A user account identifies the customer. An access profile defines what that customer may do. Limitations keep each session inside those rights. A payment record decides whether the account has access at all. An active session shows the customer in use. Accounting then writes the usage back, which feeds the next billing decision.
If you already run MikroTik hotspot billing or plan to, this loop is the foundation under it. Once you see each piece and the hand-off between pieces, MikroTik RADIUS billing stops feeling like a pile of separate settings and starts behaving like one reliable system. The sections below follow the loop in order, starting with the tool that holds most of it together.
2. Role of User Manager Inside RouterOS
User Manager is the part of the RouterOS world that gives you somewhere to keep the records billing depends on. MikroTik User Manager stores your user accounts, groups the rules that apply to them, holds the profiles and limitations that define service, and keeps the session and usage data that come back from your routers. In RADIUS terms, it plays the RADIUS server role: it receives questions from the router and answers them.
For billing, that matters because every decision about who may connect, for how long and under what conditions comes from the same source of truth. You do not want access rules on the router in one place and customer records in a spreadsheet somewhere else. RouterOS User Manager keeps the rules and the records together, so the answer a customer receives at login reflects what the account is entitled to right now. If you want the background on why operators use RADIUS, that article covers the reasoning. Here, the focus stays on how the pieces connect.
2.1 Where User Manager Sits Among Routers and Clients
Picture a few layers. Customers sit at the edge, using phones, laptops and other devices. Your MikroTik router sits in the middle and controls the door. User Manager sits behind the router and holds the knowledge about who is allowed through.
The router acts as the RADIUS client. That name confuses people at first, because the customer’s device is not the client in RADIUS terms. The router is the client because it is the one asking questions. User Manager acts as the RADIUS server because it answers them. You will also see the router described as the Network Access Server. This simply means the device that customers connect through to reach the network. It does not decide on its own whether a customer deserves access. It asks the RADIUS server, then enforces the answer.
Keeping these roles straight helps when something goes wrong. If a customer cannot connect, you can ask a clear question: did the Network Access Server ask, and what did the RADIUS server say?
2.2 When to Use Local User Manager Instead of External RADIUS
The choice between local User Manager vs external RADIUS comes down to where you want the RADIUS server role to live. A local User Manager runs inside RouterOS on a device you already manage. An external RADIUS server runs separately from your routers.
Local User Manager makes sense when you want a simple, contained setup, where the same team that manages the routers also manages customers, and you do not need billing logic to live outside the network equipment. It keeps the number of moving parts small, which suits a small operator who values straightforward day-to-day work.
An external RADIUS server makes sense when you want billing records and customer data kept apart from the router layer, or when your business wants the billing system to be a separate service in its own right. The MikroTik RADIUS billing model stays the same either way: users, profiles, limitations, payments, sessions and accounting. Only the location of the RADIUS server changes. If you ever see User Manager vs RADIUS explained as a competition, remember that it is really a placement decision, not a different way of billing.
3. How RADIUS Authentication Requests Flow
Every billed connection starts with the same story. A customer tries to connect. The router needs to know whether to let them in. It asks the RADIUS server. The server checks its records and replies. The router then acts on the reply.
That sequence is the RADIUS authentication flow, and it is worth holding in your head as a simple chain: connection request, question, record check, decision, enforcement. Nothing about it is mysterious once you see it as a conversation between the router and the place that holds the customer records. For a deeper walk through the hotspot side of this conversation, see RADIUS authentication flow explained.
3.1 What Happens Between Router and User Manager
When a customer attempts to connect, the router collects the credentials the customer presents and passes them to User Manager as a request. At this point the router has not decided anything. It is acting as a messenger.
User Manager receives the request and looks up the matching user account. It then checks whether that account is in a state that allows access: whether it exists, whether it is active, whether payment status permits service and whether any rule on the account blocks the attempt. The check is a matter of comparing the request against stored records. No part of this requires you to touch the router once the pieces are in place.
3.2 How Authorization Decisions Are Returned to the Router
After the check, User Manager sends back a reply. The simplest reply says yes or no. A yes also carries information about what the customer is permitted to do. This is the RADIUS authorization response, and it is where the profile and its rules reach the router.
Think of authentication as proving who the customer is, and authorization as stating what that customer may do. A customer may be recognized correctly and still be refused, for example because the account has no active service. When the answer is yes, the router uses the details in the reply to enforce the service boundaries tied to that account for the length of the session. The router does the enforcing. User Manager does the deciding.
4. How User Accounts Connect to the Billing Structure
A user account is the anchor for everything else. Profiles attach to it. Limitations apply through it. Payment records link back to it. Usage records come back to it. If the account is unclear or duplicated, every other part of the billing model becomes harder to trust.
For that reason, treat the account as the single identity for a customer’s service. One customer, one clearly identified account, and everything else hangs from it. If you want more on keeping that identity tidy as your customer base grows, hotspot user account management is a useful companion read.
4.1 Types of User Records Used for Billing
In generic terms, MikroTik user accounts fall into a few practical kinds, based on how the customer is meant to use the service. Some records identify a named customer who comes back repeatedly and pays on an ongoing basis. Others identify short-lived or voucher-style access, where the record exists mainly to carry a single purchase of service.
What matters for billing is not the label but the job the record does. A good billing record does several jobs. It identifies the user clearly enough for the router and the RADIUS server to recognize them at login. It carries the access rights through its profile. It gives payments a place to land, so that when money arrives, you know exactly which account it belongs to. If a record cannot do all three, you will feel it later, usually when a customer says they paid and you cannot show where.
4.2 How User Groups Organize Access Rules
When you serve many customers, managing rules one account at a time becomes tiring and error-prone. MikroTik user groups solve this by letting you organize accounts into sets that share the same access rules. Instead of repeating the same rule on every account, you apply it once at the group level and let each member inherit it.
A simple example: suppose you offer a standard service level for households and a different one for small businesses. Placing households in one user group and businesses in another means a change to the household rules reaches every household account without you touching them individually. The group is the management layer, and the account is the individual identity. Together, they keep the structure predictable as it grows.
5. How Profiles Define Access Rights
Once the router knows who the customer is, it needs to know what that customer is allowed to do. That is the job of the access profile. Where the user account answers the question “who is this?”, the profile answers “what did this person buy?”
The profile is the bridge between a commercial offer and a technical result. Your price list describes services in business terms. The profile translates that description into rules the router can enforce. When a customer pays for a given service, the profile attached to their account is what turns the payment into real access.
5.1 What a Profile Contains
In generic terms, MikroTik access profiles gather together the rights and boundaries of a service. A profile describes what the customer is permitted to use and the conditions that surround that use. It also ties to the limitations that control how a session behaves, and it can define how long the service stays valid once it is activated.
Think of a profile as a service definition written once and reused many times. Every account with the same profile receives the same treatment. That consistency is what makes billing reliable: customers on the same service get the same result, and you can explain it to them without exceptions.
5.2 How Profiles Assign Time and Data Limits
Among the most common boundaries a profile expresses are time and data limits. A time limit controls how long a customer may stay connected or how long their service remains valid. A data limit controls how much usage a customer may consume under that service.
Conceptually, the profile does not count anything itself. It states the rule, and the rest of the system measures usage against that rule. A customer on a time-based service is judged against the clock. A customer on a data-based service is judged against recorded usage. Some services combine both. The profile gives you the vocabulary to describe these offers, and the later sections show how the measuring and enforcing happen.
6. How Limitations Control Sessions
A profile states what a customer may do. Limitations make sure the customer stays within it. This is the point where how MikroTik profiles and limitations work together becomes practical: the profile sets the rights, and limitations are the checks that apply those rights to each session as it unfolds.
Without limitations, a profile would only be a description. With them, the service boundaries become real constraints that follow the customer’s session from start to finish. They also protect your business, because they keep individual customers from using more than their service allows.
6.1 Types of Limitations Applied to Users
MikroTik session limitations come in several generic kinds, each tied to a different part of how service is used. Some concern time: how long a session may last or how long a service remains valid. Some concern data: how much traffic a customer may use. Others concern the shape of the service itself, such as the boundaries that apply while the customer is connected.
You do not need to memorize a list. What matters is the principle. Every limitation answers a question about the service the customer bought, and every limitation links back to the profile that defines it. When you design a service, ask yourself what the customer is paying for, and then ask which limitation expresses that promise in a form the system can check.
6.2 How Limitations Are Enforced During Active Use
Enforcement is about ongoing control, not a single check at login. Once a session starts, the system keeps comparing what the customer is doing against what the profile allows. That is how MikroTik session limits are enforced: continuously, as usage builds, rather than only at the moment of connection.
When the customer stays within bounds, nothing visible happens. When the customer reaches a boundary, the system acts on it, and the router responds according to the rule that applies. The customer’s experience changes to match the service they have available. This ongoing control is what lets you trust that a service sold on a boundary actually respects that boundary.
7. How Payments Extend or Activate Access
Everything so far describes what a customer may do. Payments decide whether they may do it right now. This is where money received meets service allowed, and where many small operators lose confidence in their billing. If payments and access are managed separately, the two drift apart, and every drift becomes a support call.
The goal is payment to access activation that happens through the same records the router relies on. When a payment is recorded against an account, the account’s state changes, and the next authentication request reflects it. That is how MikroTik payments activate user access without anyone adjusting the router by hand.
7.1 How Payment Records Relate to User Accounts
A payment record is a note that money was received for a particular customer’s service. The important idea is linkage. The payment record points to a user account, and the user account carries the profile that defines what the payment buys. Follow the chain and you can answer the question every operator eventually faces: this customer paid, so what are they entitled to?
Keep the linkage simple and visible. A payment that cannot be matched to an account is a problem waiting to happen. A payment that always lands on the right account gives you a clean history you can show a customer, your accountant or your own team. The record also gives you a reference point when a customer disputes what they received.
7.2 How Payment Status Changes Access Availability
Payment status is the switch that turns access on, extends it or stops it. When a payment is recorded for an account, that account becomes eligible for the service its profile describes. This outcome is called activation when access begins for the first time and extension when an existing service continues. When payment is missing or has lapsed, the account no longer qualifies, and the next time the router asks, the answer reflects that.
Notice what this means for your workload. You do not toggle access by hand each time a customer pays or fails to pay. The account state follows the payment record, and the authentication flow carries that state to the router. Your role shifts from fixing individual cases to making sure the records are right.
8. How Active Sessions Are Monitored and Managed
Authentication opens the door, and the session is what happens afterward. While customers remain connected, you need to know who is online, what they are doing and whether anything needs your attention. Managing MikroTik active sessions is the operational side of billing: it is where support, monitoring and enforcement meet.
An active session is the live record of a customer’s connection. It exists from the moment access is granted until the connection ends, and it carries the details that tie the customer back to their account, profile and limitations. If you want practical ideas for keeping an eye on your network as it runs, monitor active hotspot users is a good place to continue.
8.1 What Session Data Is Visible During Connection
While a customer is connected, the system can show you which account owns the session, which service applies to it, how long the session has been running and how much usage has been recorded so far. In generic terms, this is the information a support person needs at the moment a customer calls.
Visibility turns vague complaints into specific questions. If a customer says they cannot browse, you can check whether a session exists, which account it belongs to and whether usage is nearing a boundary. If a customer says they should have more service left, you can compare their claim with what the session and account records show. Good visibility saves time because it replaces guessing with evidence.
8.2 How Session Termination and Disconnect Work
Sometimes a session has to end. A customer may reach a boundary. An account may become ineligible. You may need to remove a connection for operational reasons. The phrase session termination and disconnect covers the ways a live connection is brought to a close.
At a conceptual level, termination means the system decides the session should no longer continue, and the router acts on that decision by ending the customer’s connection. A disconnect can be triggered by the customer, by a limitation or by an operator choosing to remove the connection. In every case, the end of the session is not the end of the story. The router reports the closing details back, which leads directly to the next piece of the loop.
9. How Accounting Links Usage Back to Billing
Accounting is the part of the loop that closes it. Authentication and authorization decide whether a customer gets in and what they may do. Accounting records what actually happened. Without it, you would grant access and never know how much of the service was used, which makes time and data limits impossible to trust.
This is how RADIUS accounting tracks usage for billing: the router reports session activity to the RADIUS server, and the server stores it against the right account. The stored usage then informs the next decision, whether that is a limitation being reached, a service coming to an end or a customer needing to renew.
9.1 What Accounting Messages Record
RADIUS accounting records are the evidence of usage. In generic terms, they note which account a session belongs to, when the session began, how long it has lasted, how much usage it has accumulated and how it ended. They are reports from the router about what its customers did.
For billing accuracy, this evidence matters because it comes from the device that actually carried the traffic. You are not estimating or reconstructing usage after the fact. You are reading what the Network Access Server reported. That makes the records a reliable basis for deciding whether a customer is within their service, and for settling questions when a customer disagrees with your numbers.
9.2 How Start Interim and Stop Records Complete the Billing Loop
RADIUS Start Interim Stop describes the rhythm of accounting across the life of a session. A Start record marks the beginning, telling the system that a session is now active for a particular account. Interim records arrive while the session continues, giving regular updates so that usage is tracked as it happens instead of only at the end. A Stop record marks the close and gives the final account of the session.
Together, these records give you a complete picture. Start tells you the session began. Interim keeps the picture current, which is what allows limitations to be enforced during active use. Stop finalizes the usage for that session. Each completed session adds to the account’s history, and that history feeds the next authentication request, the next payment decision and the next limitation check. This is where the loop closes: access leads to usage, usage leads to records, and records inform access again.
10. FAQ
10.1 How does User Manager differ from standard RADIUS authentication?
RADIUS authentication is the general process of a router asking a server whether a customer may connect. User Manager is a tool that can play the RADIUS server role and also holds the user accounts, profiles, limitations and usage records behind the answer. In simple terms, authentication describes the conversation, and User Manager is one place where the knowledge for that conversation lives.
10.2 How do profiles and limitations work together?
The profile sets the rights: what the customer may do and under what service boundaries. Limitations enforce those rights during the session by checking ongoing use against the profile. The profile is the promise, and limitations are how the system keeps it.
10.3 How are users linked to payments and access time?
The user account is the anchor. A payment record is linked to that account, and the account carries the profile that defines the service. When payment is recorded, the account becomes eligible for the service in its profile, and the available access follows from that. The chain runs from user account to payment record to access.
10.4 What happens to active sessions when limits are reached?
When a session reaches a boundary set by its profile and limitations, the system acts on it. The router enforces the outcome, which may mean the customer’s access changes or the session ends. The exact behavior follows the rule that applies to that service, and the closing details are reported back through accounting.
10.5 How does accounting data support billing accuracy?
Accounting data records what each session actually used, as reported by the router that carried the connection. Because Start, Interim and Stop records build a continuous account of usage, billing decisions rest on recorded evidence instead of guesses. That makes it easier to apply limits fairly and to answer customer questions with confidence.
10.6 Can one User Manager serve multiple routers?
Conceptually, yes. Each router acts as a RADIUS client and Network Access Server that asks the RADIUS server about its own customers. One User Manager can hold the records and give answers for the routers that ask it, which keeps accounts, profiles and usage in a single place. This is the idea behind the question can one User Manager serve multiple MikroTik routers: the model supports it, and the details of how you arrange it depend on your own network.