Hello clever people, can someone finish a sentence? I'm trying to get a good grasp of a concept. Will be interested in getting different takes on the same topic, so please don't hesitate to reply, even if you see some answers.

Each row in the Vendor Master Data table represents one...

@Samson Kaing it could be one vendor or it could be one purchase order line item, just depends how your vendor allocations work.

...either one Vendor contract or a collection of contracts. It really depends on the granularity and quality of data available from your source. Also agree with the comment above depends on how you want to allocate.

...supplying party, at a granularity at or below that available from the cost source, that can be integrated with all members of the cost source, and that satisfies business needs.

Coming from an enterprise master data management background, I am more accustomed to each member/row representing one instance of a real world logical entity (one row equals one vendor organization).  In our implementation of CT, the granularity of our Vendor master data was pre-defined by the vendor granularity in our cost source (disbursements from ERP system).  For example, we have 8 distinct Vendor IDs for "IBM" due to different contracts, services, and other business needs (and business practices) in our ERP system.  That dictated the granularity of and identifier used for each Vendor Master Data row in order to support allocation from the cost source.  This doesn't preclude the use of additional attributes and entities to facilitate aggregation of costs to a single identifier per organization (one row for IBM) for reporting purposes.  I try to think of our Vendor Master more like a Vendor Account that we can then roll up to a true Vendor Master if desired.

I say "party" in our case because we can make payments to individual persons or to organizations (both party master data) which may have one or more roles (supplier, employee).

Can't say I'm the best one to decide on the "correct" reply, but this is what I'd expect to find if I was 'googling' for one in the Apptio community. I come from the perspective of a data modeller. This explanation is formal (strict) enough in its language to make someone read it more than once, yet followed up with an easier one that has the finer details, shared from their practical experience and thoughts. Appreciate the final thought that one can think of it more as the Vendor Account table, that we can then roll up to the true Vendor table, if desired. Thank you! 

I agree with @Robert McGough.  One supplying party so that you can choose this name as the vendor in other areas and see what spend you have for that vendor.