B2B Relationship Graphs from Vendor, Customer and Spend Records

What a spend-derived relationship graph contains

A spend-derived graph is a set of company-to-company edges built by rolling up invoice, payment and purchase order lines between a buyer entity and its vendors or customers. The raw inputs are usually ERP vendor master and customer master tables, AP invoice lines, AR invoices and payment runs from systems such as SAP S/4HANA, Oracle NetSuite or Microsoft Dynamics 365. Each roll-up turns thousands of line items into one edge per counterparty per period. For the line-level view of those systems, see ERP transaction and master data for AI training.

This is a different product from shipment or purchase order datasets. Logistics records describe goods in motion; a relationship graph describes who depends on whom, for how much, and since when. Buyers who need lanes, carriers and fill rates should start with supply chain and logistics datasets, and buyers who need the underlying documents should look at procurement records.

Commercial precedent exists for licensing relationship networks for model training. At least one financial data vendor offers separate model-training and derivative-model licenses for datasets that include supply-chain and customer-supplier networks [1]. Networks built from public filings and disclosures tend to skew toward large listed companies and material relationships. Ledger-derived edges reach the long tail of small suppliers that disclosure-based graphs miss.

Edge schema: the fields that make a graph trainable

A trainable edge needs stable node keys, a direction, a time window and a small set of numeric and categorical attributes. Without first and last transaction dates, you cannot build temporal splits; without a category, you cannot separate a packaging supplier from a law firm. The schema below is a reasonable starting specification for a request.

Illustrative example: invented to show structure; it does not describe an available dataset.

Node tables should carry their own coarsened attributes (sector, region, size band) keyed by the same tokens. If the supplier has classified spend with UNSPSC or a custom taxonomy, ask for the taxonomy version and mapping table; the product and spend classification guide covers label quality for that layer. Deliver both edge and node tables as Parquet, whose columnar layout and footer metadata make wide edge tables cheap to scan [7], or as shared tables over an open protocol such as Delta Sharing [8].

Entity resolution decides graph quality

Entity resolution is the step most likely to corrupt a relationship graph, because one supplier appears under many names across vendor masters. "Acme Industrial Supply LLC", "ACME IND SUPPLY" and a remit-to address for a lockbox can be the same node or three. Over-merging creates false hubs that dominate degree-based risk features; under-merging fragments real suppliers and hides concentration risk.

Ask how nodes were resolved across the supplying company's own systems and, if several companies contribute, across contributors. Useful evidence includes the matching keys used (tax ID, DUNS-style identifiers, normalized name plus address), the blocking strategy, and a labeled evaluation sample. Evaluation should be entity-centric, measuring cluster-level errors, not only pairwise precision on easy pairs [4]. The entity resolution training data guide explains what a defensible match benchmark looks like.

Two failure modes recur. Parent-subsidiary rollups are often missing, so a model sees five unrelated suppliers that share one parent and one point of failure. Payment intermediaries such as factoring companies, PEOs and card networks appear as counterparties and should be flagged or removed before training.

Protecting counterparty identities without losing structure

Counterparty names in AP and AR data are usually confidential business information, and vendor masters can also hold personal data for sole proprietors. The practical answer is to tokenize node identities with a keyed hash or consistent surrogate, band monetary values, and suppress edges or node attributes that would single out a company. Consistent tokens preserve graph structure across tables and refreshes while removing names; see pseudonymisation techniques for training data for keyed hashing trade-offs.

Tokenization alone is not anonymization. Under EU guidance, pseudonymised data remains personal data where it relates to individuals and re-identification is possible with additional information [5]. A supplier with a rare combination of NAICS code, state and top spend band is easy to re-identify, so apply aggregation thresholds in the spirit of k-anonymity, where each record must blend with at least k-1 others on quasi-identifiers [6]. Graph structure itself is a quasi-identifier: a node with an unusual degree pattern can be recognized by anyone who knows the supplier base.

Contract terms matter as much as technique. Supplier agreements and customer contracts may restrict reuse of transaction data; check them using the approach in customer contracts and DPAs for training use. Large audits of AI datasets found licenses frequently omitted or wrong on public hosting sites [9], which is why a documented chain of rights matters more for commercial graph data than for public benchmarks.

Temporal edges for link prediction and disruption modelling

Relationship graphs are temporal by nature, so evaluation must respect time. Link prediction on a static snapshot leaks future edges into training and inflates metrics. The Temporal Graph Benchmark formalizes dynamic link property prediction, where models predict future edges from past interactions under a standardized evaluation pipeline [2]; mirror that setup on licensed data.

Practical requirements for a temporal request:

• Edges are emitted per period (monthly or quarterly), not as one lifetime aggregate.
• first_txn_date and last_txn_date come from posting dates, with late-arriving invoices handled consistently; the point-in-time correct training data guide covers as-of joins.
• Node attributes are snapshotted as of each period, so a supplier's later size band does not leak backward.
• Disruption labels (supplier churn, sudden spend drop, category switch) are defined in writing before the split.

For knowledge graph enrichment and LLM grounding, relationships are core context: enterprise KG research frames the relationships between entities as core context for language understanding [3]. Typed edges such as "supplies category X to" or "invoiced under contract" are more useful to retrieval and KG completion than untyped co-occurrence links.

Buyer request checklist for relationship edges

A precise request is the fastest way to learn whether a supplier's ledger can produce the graph you need. Describe the data, not specific companies, and keep the first ask small enough to evaluate.

Illustrative example: invented to show structure; it does not describe an available dataset.

• Use case: supplier concentration risk scoring, quarterly link prediction, KG enrichment for procurement copilots.
• Perspective: AP edges (company to its suppliers), AR edges (company to its customers), or both.
• Grain: one edge per counterparty pair per quarter, 2019 to present.
• Required fields: tokens, direction, period, first/last transaction date, spend band, invoice count band, category code, contract flag.
• Node attributes: NAICS 2-digit, US state or region, size band, all coarsened.
• Entity resolution: method description, keys used, labeled evaluation sample, parent-child rollup if available.
• Confidentiality: keyed tokens, banding scheme, minimum cell size, suppression log.
• Exclusions: individuals, payroll, intercompany transfers, payment intermediaries.
• Format and delivery: Parquet edge and node tables, data dictionary, row counts per period.
• Refresh: whether new periods are needed; see ongoing data supply agreements.

Before committing, ask for a schema and a representative sample, following how to request a training data sample. Check degree distributions, edge churn between periods, and whether the share of spend with no category code is low enough to use.

How SourceX approaches relationship data requests

SourceX sources operational datasets from US companies on request; it does not hold relationship graphs in stock, and a request does not guarantee a match. Buyers describe the data they need, SourceX looks for US businesses that hold it, and every release is approved by the supplying company. The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. You can describe a supplier network data need to SourceX to start that process.

Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. SourceX does not source scraped web content or standalone contact lists and does not publish prices; what it may do with a deidentified dataset is set out in the signed supplier agreement.

For adjacent tabular needs, the structured data buyer's guide maps the cluster, and the AI data hub covers rights, privacy and procurement across all data types.

Sourcing supplier network data for AI

If your supplier risk or link prediction model needs edges from real vendor, customer and spend records, SourceX can look for US companies that hold that data and manage licensing with the supplying company. Datasets are rights-reviewed and delivered under a license that defines records, uses, term and delivery. Start a supplier network data request.