A better design would be to have a single table to hold all the parties to a payment. If necessary, sub-type this table so companies, proprietors and customers have their own, unique sets of columns (or a separate, related table).
The payments table will then have two foreign keys to
Parties, let's call them
PaymentToPartyID, along with amount, date etc. This way all permutations of money transfer can be tracked.
To find all the monies a person has received use
select sum(p.Amount) from Payments as p inner join Parties as y on y.PartyID = p.PaymentToPartyID where y.Name = 'The person/company/proprietor of interest';
A party is anyone or anything who has in interest in a payment. This would be a proprietor, customer or company, distinguished by a type:
Parties( PartyID PartyName PartyType -- customer or company or proprietor <customer-fields> <proprietor-fields> <company-fields>)
A payment relates a payer (of any type) to a payee (of any type):
Payments( PaymentFromPartyID -- FK to Parties.PartyID PaymentToPartyID -- FK to Parties.PartyID Amount Date etc.)
The IDs used in From and To says in which direction the money flows. There is no need to have any information about a party in the Payments table, such as a type, other than the two PartyIDs.
To get all the payments made to customers (for example) add
Parties.PartyType = 'Customer' to the query given above.
The Payments_Track table you list has all the attributes I list here (bar a few surrogate IDs) but is normalised.