Up to about ten clients, running a reseller business by hand is fine. You create accounts in WHM, send invoices, and remember who has paid. Past that it stops working, and it stops working in a particular way: not dramatically, but through a slow accumulation of accounts you forgot to invoice, invoices you forgot to chase, and clients who have not paid in four months still being hosted because suspending them felt awkward.
Billing software connected to WHM fixes all three, because it stops being a thing you decide to do each month and becomes something that happens.
What the connection actually does
Billing software talks to WHM over its API. Once connected, four things run without you.
Provisioning. A client orders, pays, and the cPanel account is created automatically with the right package. Their welcome email with login details and nameservers goes out immediately. No manual step, at any hour.
Invoicing. Invoices generate and send on schedule, with reminders before and after the due date.
Suspension. An invoice passing its overdue threshold suspends the account. Payment clearing unsuspends it, usually within minutes.
Upgrades. A client changing plan in your portal triggers the package change in WHM and adjusts the billing at the same time.
The suspension piece is worth dwelling on, because its value is not only time. Automated suspension is consistent and impersonal. It applies the same rule to everyone, and it removes the recurring decision about whether to chase a particular client this week, which is the decision most people quietly avoid until an account is six months overdue.
Connecting it
The details differ between billing products, but the shape is the same.
Add your server in the billing software: hostname, your WHM username, and an authentication token generated in WHM rather than your password. Use the token: it can be revoked without changing your login, and it does not sit in a configuration file as a password that also opens your control panel.
Set the connection to use SSL and port 2087. Then use the test button. A connection that fails here fails silently later, at the worst moment: a client pays, nothing provisions, and you find out when they ask where their account is.
Next, map your products to your WHM packages. Each product in billing points at a package name in WHM. This mapping is fragile in one specific way: renaming a package in WHM breaks it, and the failure is silent. If provisioning stops working after you tidied up your packages, this is why.
Finally, decide what automation to switch on. Auto-provision on payment, yes. Auto-suspend on overdue, yes, with a sensible threshold. Auto-terminate after a long overdue period is worth thinking about harder; it deletes data, and a card that failed to renew looks identical to a client who has left.
Setting the thresholds
The suspension threshold is the setting that matters most, and it is a judgement about your clients in place of a technical choice.
Too short and you suspend people whose card expired, which is a bad experience for someone who fully intended to pay. Too long and you host free of charge for months. Somewhere between seven and fourteen days after the due date works for most reseller businesses, with reminders before the due date and again on it.
Be much more conservative with automatic termination. Suspension is reversible; termination is not. Setting termination to run automatically at thirty days will eventually delete a client who was in hospital. If you use it at all, set it far out and take backups first. There is more on why the manual checklist exists in terminating client accounts.
Test before a real client meets it
Place an order in your own system, pay it with a real payment method, and watch what happens. Then let a test invoice go overdue and confirm the account actually suspends. Then pay it and confirm it comes back.
This takes half an hour and finds the mapping that points at a package you renamed, the welcome email still containing placeholder text, and the suspension that does not fire because the threshold was set in the wrong unit.
Read the welcome email as a client would. It is the first thing they receive from you, and it needs to contain the cPanel address, their username, their password and the nameservers to point their domain at. Missing nameservers generates a support message every single time.
Where the two systems disagree
The one ongoing hazard is drift: WHM and billing each hold a view of reality, and nothing forces them to match.
An account terminated in WHM but not cancelled in billing keeps invoicing for hosting that does not exist. An account created by hand in WHM for a client who bypassed the order form never gets invoiced at all, and because it works perfectly, nobody notices for a year.
That second one is the expensive one, and it comes from creating accounts manually out of habit. Once billing is connected, create accounts through billing even when it feels slower. The exception is a genuine one-off, and then record it immediately.
Worth doing every few months: compare the account list in WHM against active services in billing. Anything in one and not the other is either lost revenue or an invoice you should not be sending. Managing customer resources goes into the WHM side of that inventory.
Automated billing also produces the disputes people raise with their bank rather than with you. How to Handle a Chargeback or Billing Dispute explains handling them.