First of all you don't need to convince them with any argument. You're a freelancer then things are formally regulated by your contract.
This depends on your contract specifics but if you are freelancing it's reasonable to assume that any feature has to be accepted to be considered done. If not then this is the absolute first thing to change.
After it's done they MUST pay for any change, including bugs.
While in progress they MUST pay for any bug caused by incomplete or wrong specifications, changes, and external causes (faulty driver, OS updates...). However this might be hard to determine, see later.
Your own mistakes before acceptance might be in a gray area but your EXISTING contract should clarify this. They can't change contract unilaterally more than you can start charging a different hourly rate.
In my experience not charging bugs is controversial because the root cause is often opinionated then it's usually easier for everyone to count them as part of the development process. Wouldn't use some more time to implement that feature correctly from beginning? How much more? Is it caused by an incomplete or unclear specification? New code crashes because of a bug in old code? Old code crashes because of new code? You definitely don't want to play this game on a daily basis.
If you're working with UI then it's even more obvious: a good and sane approach is iterative (with frequent user testing sessions) and some findings are borderline to be bugs (even if you literally and correctly interpreted specifications). I'm sure you experienced this and you know what I mean (for example I'd tend to consider a bug a text box to enter a path without autocomplete, even if specs didn't explicitly mention this feature).
If you need to have this kind of discussions you hardly will go along well with them and you will waste your time and money, to track down a bug might even take days.
If they don't agree on this then walk away IMMEDIATELY, you may like the job but, unless you're ready to give away a possibly significant part of your salary (or to fight for each single bug), you will be the one always loosing something.
Alternatively, assuming you're doing your best to deliver good quality software:
- If they want to renegotiate the contract (and you're willing to do so) you can change your hourly rate to compensate time that you will spend to fix bugs (now you probably have enough data to extrapolate a number). This will cost more money but it's still easy for them to plan for those costs from the updated hourly rate and previous projects/code development speed.
- You do not deliver a feature until you performed all the tests, with all the tools, a tester would do. Of course you charge this as a developer, not as a tester. They'll see that, usually, it's cheaper to let some bugs to be found by testers. Be careful because the definition of what a bug is must be formally agreed. If you are already using all the tools to reasonably deliver bug-free code (the fact that they found some using an automated tool is suspicious) then this will cost much more money to the company because development/testing/fixing estimation is merged together and less predictable. They absolutely need to be aware of its implications because they're paying a developer to do tester's job, including monkey testing which is always part of it.
In my experience if you pick option 2 then you'll also obviously incorporate option 1 (there will always be bugs and no one works for free) then overall costs are doomed to increase. Whenever possible a trusty, sane, and professional relationship should avoid them both.
One side note: don't fool yourself thinking that you can find all the bugs a tester can find. Software testing is a different expertise, a separate art, which needs time to be mastered and it's not just about unit/integration/regression/stress testing (which you MUST already have in-place). Of course you can learn to be a good tester but it won't happen in one day.