I built an app which was sold to the public that had a similar type of requirement. The app was used to do a benefits audit. In some cases, the app was purchased by a company for its own internal use and in others, it was purchased by a third-party who used it to perform the audits for multiple clients. This seems to be your situation. You want to control the number of companies that the database can be used for.
In our case, the product was licensed for x concurrent audits. So a company doing its own internal audit would buy 1 license. They would perform the audit and archive the results. The following year, they could do another audit using their single license. Or, they could run the audit all year and do a department at a time. The point was that they could have only one active audit at one time. For the clients who were performing audits for other companies, they might buy 3 or 10 licenses depending on how many concurrent audits their staff could handle.
The only way to control this is to have ONE back end database to hold the data for ALL the concurrent audits and you could do something similar. The way you control the concurrent audits or clients or whatever is by limiting the number of rows in the top level table. So in our case, we allowed only as many records in the audit table as the customer purchased licenses for. Your case would be clients. So the application allows only x client records depending on how many licenses the account purchases.
To facilitate this, I wrote code to generate a "token" that was given to the purchaser of the application. In it was encoded the number of licenses and the end date of the license period as well as several other y/n options applying to features the client elected to purchase as extras. So 1 license for 1 year or 3 licenses for 1 year or 6 licenses for 2 years. Whatever we agreed on. In our case, we weren't really worried about the customer giving the software to some other company since any other company would be a competitor of theirs and why would they give them something of value with which to beat them in the marked. It was more likely that they would try to use the software for more audits than the bought or to use the app after the expiration date. Our code prevented both of those things from happening.
One thing we never implemented because it seemed to be over kill but which you might want is to have the software either log into a web page periodically and send you the name of the BE it was linked to or if the user used the relink form, which our app included), that might be where you want to send yourself an email so you could determine if the client was cheating by linking/relinking every day to work on a different BE so he could support more customers.
Make the cost of a license reasonable enough that your customers won't have any real incentive to circumvent your licensing and make your contract have real punishments should the client be found to be violating your terms.
I can't give you the code I used to generate/interpret the token but I can give you some guidance on how I did it. PS, if you go with the "ET phone home" techniques, you must inform the client and have it included in your contract so they know what information you are going to send yourself.
