When your database grows beyond what you're able to backup in an hour, you need a different model.
A Full backup of your database will truncate your logs, but it needs to be "SQL aware", because in that scenario, it's the backup software that's telling SQL server what it has backed up, and what to truncate.
As others mention, if you have a database in the "Full" recovery model, it's transaction log will grow indefinitely, until you make a Full SQL-aware backup.
Recovery is really the issue here, not Backup. And it's not a technical decision, its a business decicion!
If your business owners are OK with losing an hour or more of their database transactions (which may be VERY difficult or impossible to redo!) then your model works. If they are OK with the system being down for hours while you restore the whole database from backup, then your model works.
However, if your business regards their ERP system as a critical asset for their operation (don't they all?), then setting a maximum acceptable recovery time (aka RTO, Recovery Time Objective) for your critical services will be a business decision.
Also, the business owners or system stakeholders need to define how much data they are willing to risk losing in an incident, aka RPO (Recovery Point Objective).
The answer if you ask them might be "NO data can be lost! The ERP system must be available 24/7/365!"... which we all know is highly unlikely to be cost-effective. If you present them with the cost associated with building such a fully redundant, non-stop system, they will come up with more reasonable figure.. ;)
The point is, if you can avoid losing any transactions, you're saving your business potentially hundreds or thousands of lost work hours. It amounts to HUGE savings in any company, and grows with the size of your company...