Yeah, not getting why anyone would complicate a customer acct table by making two of them. I also don't understand why OP is talking about a hierarchy, unless a single customer has multiple accounts. But that is still doable with a single table using a parent key.
Surprised it took so many posts to arrive at this. Your entity is a customer, regardless of what type. A flag works, or if you like have a CustomerType set up to allow you to define other types of customers outside of individuals and companies in the future.
You're dealing with 3 things here, Customer, Companies, and People. You could take it even further by describing what each three things have, for example contact info like addresses and phone numbers. So Customer, Companies, People, and Addresses for example. With this data you could create Views that combine data from any or all of these tables. Customer for example could be a View of Companies, People, and Addresses. Views are fast, secure, and very flexible.
Im just trying to think through the problem. Think is my usual process to find the best dolution for me. My main thing really is kerping my update queries as simple as possible.
And that is why you use one table for customer accounts. It doesn't matter if they are a person or a company; they should all have a customer id coming from the same table, or your JOINs to other info are waaaay too complicated. And further splitting account detail into separate tables based on person vs business is fine, but unnecessary.
