Design option when a type can be one of two different things

Lets say I have a Customer type, and there's certain information I want to store for all customers. However a customer can be either a Person and an Organisation. In each case I would want to store different types of information on them, and have the ability to act on them in different ways.

I would normally want to deal with just the Customer object, but at certain times depending on situation deal with the more specific type differently (an example might be that when creating an address I want to use Surname and GivenNames from a Person, but the TradingName (but it not populated then OrgName instead) for an Organisation.

I'm torn on how to handle this. The examples/questions I find while searching assume the more specific types have the same properties/methods so can be treated generically.

Do I just have a field for either type in my Customer object and a flag to indicate which has a value (i.e., isPerson()) and check that in my code when I need to. Do I use inheritance and when needed use IsType() type of logic? Or is there some design pattern I'm missing that helps with this type of scenario?