PRODUCT DATA
Why product data belongs next to the ledger
Margin by SKU, stock value, ad spend per order: the questions that cross finance and catalog data, and the case for keeping both on one data model.
By Unify Int team4 min read
- product-data
- commerce
- data-model
Most integration stacks split the world in two. Finance data lives in one pipeline: ledgers, invoices, payments. Product data lives in another: catalogs, stock, orders, ads. Different vendors, different schemas, different teams.
That split looks tidy until someone asks a business question. Then it falls apart, because almost every question worth asking crosses both sides.
The questions that cross the line
Here are questions commerce, lending and finance products are asked every week:
- What is our margin by SKU? Revenue is in orders and the ledger. Cost is in the ERP item master or purchase orders. Fees are in marketplace settlements. Returns are in yet another place.
- What is our stock worth? Quantities are in the warehouse system or storefront. Unit costs are in the ERP.
- What did that ad campaign earn? Spend is in Google Ads or Meta Ads. Orders are in Shopify or Amazon. Refunds and fees change the answer.
- Is this merchant creditworthy? Lenders look at the P&L, bank balances, sales velocity and ad efficiency together.
- Why does the payout not match the orders? The marketplace deducted fees, refunds and reserves. The ledger shows one deposit.
None of these can be answered from finance data alone or product data alone. If your product needs to answer them, it needs both, joined.
Why joining later is expensive
The usual workaround is to pull everything into a warehouse and join it there. That works, eventually. It also creates a project that never ends.
Identity is the hard part
The same product has different ids in every system. The PIM has a product code. Shopify has a product id and variant ids. Amazon has an ASIN and a seller SKU. The ERP has an item number. Matching them needs rules: SKU, GTIN or UPC, or a custom key. Those rules break when someone renames a variant.
Money flows don't line up
An order is not revenue until it settles. A marketplace payout covers dozens of orders, minus fees, refunds and reserves. The ledger may record one summarized journal entry per payout. Linking an order line to the ledger entry it eventually produced needs a model that understands both sides.
Time and currency
Ad platforms report daily metrics in the ad account's timezone and currency. Storefronts report orders in store time. Ledgers close by period in the company's base currency. Joining without normalizing creates numbers that are almost right, which is worse than wrong.
Every new platform restarts the work
Add a new storefront or a second ERP and the joins need updating. Each integration was built against its own schema, so nothing carries over.
What one model changes
Putting product data and finance data on one data model moves the joins from your warehouse into the integration layer. The links exist when the data arrives.
In practice that means a few linked objects:
| Object | Links to |
|---|---|
| SKU | Product, inventory levels, order lines, ad insights |
| Order | SKUs, fulfillments, refunds, the payout that settled it |
| Payout | Orders, fees, refunds, the journal entry it posted |
| Journal Entry | Accounts, the payout or invoice behind it |
| Campaign | Insights, the orders it drove (where attribution exists) |
With those links, "margin by SKU" becomes a query rather than a project. You read the SKU with its orders and costs expanded:
curl "https://api.unifyint.com/v1/product-data/skus/sku_01JC9B7Q2D?expand=inventory,orders" \
-H "Authorization: Bearer $UNIFY_API_KEY" \
-H "Unify-Connection-Id: conn_shp_4k8n2"The response carries quantities by location, order lines with amounts as decimal strings, and ids you can follow to payouts and ledger entries.
Product identity, done carefully
Matching products across systems is where most shortcuts cause damage. A careful approach:
- Match on explicit keys. SKU, GTIN/UPC or a key the customer chooses.
- Report conflicts. Two items with the same SKU in different systems should produce a match report, not a guess.
- Keep variants first-class. Size and color variants each have their own SKU, stock and sales.
- List bundle components. A bundle sells as one line but draws down several SKUs.
Writing back matters too
Reading joined data is half the value. Commerce and operations tools also need to write: push enriched attributes to channels, adjust stock, send tracking numbers, post settled revenue to the ledger.
Those writes need the same care as finance writes. Stock should change through adjustments, not overwrites, so concurrent updates don't clobber each other. Ledger postings need validation and idempotency. Marketplace listing updates must respect each marketplace's rules.
Who benefits
- Multichannel commerce tools reconcile catalog, stock and orders across Shopify, Amazon, Walmart and an ERP.
- Lenders and revenue-based financing providers underwrite on sales, ad efficiency and the P&L together.
- Accounting tools for ecommerce post payouts correctly, with fees and refunds split.
- Inventory and planning tools value stock using ERP costs and live quantities.
- AI agents that answer "which products lose money?" need linked data, not five disconnected APIs.
Questions to ask your integration layer
If you are evaluating how to join product and finance data, ask:
- Do product objects and ledger objects share one schema, or two?
- Can I follow an order to the payout and journal entry it produced?
- How are products matched across systems, and what happens on a conflict?
- Are variants and bundles modeled, or flattened?
- Can I write stock, prices and attributes back, and are those writes idempotent?
How Unify Int fits
Unify Int puts Catalog/PIM, Inventory, Orders & Commerce and Ads APIs on the same data model as Accounting, Payments and ERP: the Unify Graph. A SKU links to its stock, its orders, its ad spend and the revenue it posted.
See Product Data, the Unify Graph, or the multichannel commerce use case.