I know you said you are not referring to inheritance, but the best literature concerning your case all refer to inheritance in describing the problem, and proposing a solution.
There are a handful of websites that give detailed solutions on how to design relational tables that express the type/subtype or the class/subclass relationship. The most important thing is to use the right buzzwords in your search.
In Entity-Relationship modeling between customers, companies, and persons is called "generalization/specialization". A search on this will give you lots of good material. Companies are specialized customers, and so are persons. another useful buzzword is "IS-A relationships".
In relational modeling, there are three techniques that have been widely shared for covering this kind of problem. Here they are "single table inheritance", "class table inheritance", and "shared primary key". I know the word inheritance appears there, but trust me, a search on these items is going to give you some articles that address your specific case, although they may be talking about autos, trucks, and vehicles or dogs, cats, and pets instead of companies, persons, and customers.
Some of the hits you will get will lead you right back here, to stackexchange.dba. Others will lead you over to Stackoverflow, where there are three tags to collect information about the three techniques.
The only thing not covered in detail is how you add constraints to enforce the mutual exclusion rule, what you have called XOR. If you use shared primary key, the constraint for mutual exclusion will be much like what you have already presented, only simpler.
To summarize what all this means in your case:
You will have four tables: transaction, customer, person, and company.
Transaction will contain a customer_id field, which references the id field in customer. Customer will have an id field, probably filled in by an autonumber feature, as is commonly done. Person does not have an id field. Instead, it has a company_id field that acts as both a primary key and a foreign key referencing company.id. Company is treated the same way as person, with a company_id field that is both a PK and an FK.
The customer table can contain fields, if any, that pertain to both companies and persons.
Finally, you will need a constraint in the person table that says that customer_id is not in the company table, and one in the company table that says that customer_id is not in the person table.