Introduction to ISP Billing

An operational platform for ISPs

ISP Billing brings an Internet Service Provider’s daily work into one platform: customer acquisition and management, quotes, contracts, recurring or rechargeable services, billing, collections, support, field work, and network control. It is not merely an invoicing application: it connects commercial data with technical operations and keeps the relationship history under the same customer profile.

Each area has a distinct responsibility. CRM stores the customer record; the catalog defines what the ISP sells; a service instance represents what one customer actually uses; contracts, quotes, and invoices formalize the relationship; tickets and activities record work; network modules and providers execute or read technical operations.

Before starting: configuration versus operation

Almost every function requires preparation. Enabling a module makes menus and permissions available, but it does not automatically configure numbering, price lists, templates, gateways, external accounts, or operating rules. Configure the module first, test one complete journey with demonstration data, and only then use it in ordinary work.

For example, creating a customer is not enough to issue a correct invoice. ISP tax identity, numbering, document types, VAT, payment method, billable service, and electronic delivery must all agree. Read each guide’s configuration sections before its daily procedures.

The working model: customer, service, and document

The customer is the starting point, not the whole process. Associate a catalog service, complete the required provider provisioning, define billing start and cycle, and attach the required commercial documents.

When data does not agree, trace the chain: identity and contacts; contract or order; service instance; technical profile; billable item; invoice and payment. Editing only the final document can conceal an upstream setup problem.

Roles, permissions, and active modules

Two operators in the same ISP can see different homepages and menus. Availability depends on the active module and role permission; some functions additionally require complete settings or a valid provider account.

If an item is missing, check licence, module activation, account role, and configuration. Do not grant broad administrator access merely to solve one missing function; assign the permission that matches the operator’s responsibility.

Finding your way around the interface

The sidebar organizes authorized modules by business area. The top bar contains quick search, settings, profile, notifications, and interface controls. The homepage gathers indicators, alerts, and shortcuts and should be the first daily checkpoint.

Dashboard figures are operational links. A counter describes a population or queue; open the linked list and verify individual records, status, dates, and ownership before acting.

On smartphones, widgets are stacked into one column to fit the screen while retaining the format selected during customization. Resizing the window does not change or replace the saved configuration.

How to use this documentation

New users should read Introduction, Getting started, Dashboard, and System and module settings in that order. Then open the guide for the process being configured. Do not stop at “how to create”: read prerequisites, settings, states, final checks, and common errors.

• Search for the label shown in the interface, a provider, or a field.
• Follow the documented order and complete dependencies first.
• Use cross-links when a journey spans several modules.
• Verify the saved state and any resulting automation.
• Never copy real credentials or customer data into examples.

Screenshots and sample data

Screenshots contain fictional information for illustration. Before repeating a procedure, replace every value with verified data, review recipients and automations, and select the correct environment for each connected provider.