I'm afraid adding a Web Service layer is probably the correct solution to your problem.
Separating the client from the underlying database implementation will probably help you in the long run too.
Adding a web service layer doesn't necessarily have to hurt performance...
Indeed, with an appropriate API, a web service can actually improve performance, by batching together multiple database queries within the data center LAN, rather than requiring multiple round trips over the WAN.
And of course a web service layer can often be scaled horizontally, and add appropriate caching to your database queries, perhaps even a change notification mechanism.
A server layer adds security that you cannot possibly ensure with apps running on a remote client. Anything that runs on a client can be "hacked" and should not really be considered in any way trusted. You should only really put presentation logic in the client, and host anything important on hardware you have complete control of.
I don't know about your apps, but my web apps are naturally split into several layers, with the presentation code separated from the persistence layer by at least one level of business logic that keeps the two apart. I find this makes it much easier to reason about my app, and so much faster to add or modify functionality. If the layers are separated anyway, it is relatively easy to keep the presentation layer in the client, and the rest on a server under my control.
So while you can solve your problems without introducing a "web service" layer, by the time you have written all the stored procedures (or equivalent) necessary to fill in the holes in the standard database security implementation, you would probably be better off writing a server-side application that you can write proper unit tests for.
Since you are using this information for billing purposes, I do not see why you would not want it in the database where it can be easily queried, aggregated, reported on, and joined to other data.
I also think it's much easier to maintain a single database table containing the log information than a bunch of separate log files. Same with your concern about the load on the server - there are much better ways of dealing with that than resorting to keeping data in flat files.
Your third option, by the way, is to do both. Use the database for most needs, but have the log file for auditing purposes.
Best Answer
Another advantage of using the ad account or similar is that in your database itself you can run in built in functions to work out who is logged in. This can be useful for things like auditing, or to know who is accessing your database at any point in time using the tools provided by your database.
However as previously mentioned this doesn't scale particularly well. Lots of open connections on your database via different users is expensive in terms of server resource.
Using either scenario, for most larger apps, you're going to have a users table either way. Whichever authentication method you use, once you know who that user is you will likely need to know more about them - what their date if birth is, their nationality, financial authorisation limits, permission to click on the save button... Very often you will use a users table and associated tables to store whatever you need to know for the app.
Some frameworks, such as asp.net for example, provide tools that will automatically give you templates for maintaining your own user tables.