New Party Records (30d), Oracle ERP Cloud

New Party Records (30d) from Oracle ERP Cloud. Count of new Party records created in Oracle Fusion’s Trading Community / Party model in the last 30 days versus the prior period, tracking customer-base growth and data-onboarding volume.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

Count of new Party records created in Oracle Fusion’s Trading Community / Party model in the last 30 days, compared to the prior period. Tracks customer-base growth and onboarding volume.

At a glance

The number of new Party records, customers and accounts, created in the Oracle Fusion Trading Community Architecture (TCA) Party model in the last 30 days, compared against the prior 30-day window. This is the customer-master growth pulse: it tells you how fast new business entities are entering Oracle, whether onboarding is keeping pace with sales, and whether a sudden spike or dip in record creation hints at a data-load event or a pipeline stall. It counts the act of creating a master record, not revenue.

What it counts	The count of Party records created in the Oracle Fusion TCA Party model within the period. Includes Organization and Person party types where configured. Counts the master entity, not the number of sites, contacts, or accounts attached to it.
Currency	n/a. This is a count metric, not monetary.
Business Unit scope	Parties in TCA are global, but the card respects the dashboard’s Business Unit filter via the customer-account assignments derived from each party. By default counts every new party the connected role can see.
Time window	30D vsP (last 30 days versus the prior 30 days).
Alert trigger	None by default. A sharp spike usually indicates a bulk data load; a sharp dip usually indicates an onboarding stall.
Roles	owner, finance, marketing

Calculation

Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A US Fortune 500 B2B-plus-DTC distributor on Oracle ERP Cloud. The 30-day window covers 14 Mar 26 to 12 Apr 26, compared to the prior window 12 Feb 26 to 13 Mar 26.

Party type	This period	Prior period
Organization (B2B accounts)	410	372
Person (DTC / individual)	1,260	1,190
New Party Records (this card)	1,670	1,562

Five things to notice:

1. Up 6.9% versus the prior period. Steady, healthy customer-master growth. There is no spike that would suggest a bulk load and no collapse that would suggest an onboarding stall, so the number reflects organic acquisition flowing into Oracle.
2. The card counts parties, not accounts or sites. A single new B2B Organization party may carry several customer accounts and many ship-to and bill-to sites underneath it. This card counts the party once. If you need the account-level figure, pair with Active Customers, which counts transacting accounts.
3. B2B versus DTC split tells a story. 410 new organisations against 1,260 new persons is a typical hybrid mix. A swing toward Organization parties usually signals a wholesale or marketplace push; a swing toward Person parties signals DTC acquisition. Marketing reads this split alongside campaign timing.
4. Watch for a sudden 10x spike. A jump from 1,670 to, say, 16,000 almost always means a data migration or a marketplace bulk import ran, not real acquisition. The card will move sharply and the ecom customers absent from Fusion party card usually drops in the same window as the backlog clears.
5. A new party is not yet a customer. Creating the master record precedes the first Sales Order. Some of these 1,670 will transact this period; others are pre-loaded for a contract not yet active. To see who actually bought, use Active Customers.

Sibling cards merchants should reference together

New Party Records measures onboarding into the customer master. Pair it with these to connect record creation to real transacting behaviour and data hygiene.

Card	Why pair it with New Party Records
Active Customers	New parties are the top of the funnel; active customers are the ones who actually transacted. The gap is your activation rate.
Ecom Customers Absent from Fusion Party	The integrity counterpart. If commerce is acquiring customers faster than Oracle is creating parties, this card lags and that card grows.
Customers with TaxRegistrationNumber Mismatch (B2B)	Newly onboarded B2B parties are the most common source of tax-ID mismatches.
Customer Churn Signals	Growth on one side, attrition on the other; net customer-base movement needs both.
Top Customers by Revenue	Tells you whether new parties are diversifying the base or whether revenue stays concentrated in the same few accounts.

Reconciling against Oracle ERP Cloud

Where to look in Oracle ERP Cloud:

Navigator → Receivables → Billing → Manage Customers (filter on creation date, last 30 days) Navigator → Customer Data Management → Manage Parties (the TCA party master directly) Reports and Analytics → OTBI → Customer Real Time / Trading Community Real Time Subject Area (count distinct parties by creation date)

Manage Parties in Customer Data Management is the canonical TCA view and the closest one-to-one with this card. Manage Customers in Receivables shows the account layer, which sits one level below the party, so its counts can be higher than this card when a single new party carries several accounts. OTBI on the Trading Community subject area lets you reproduce the exact count distinct of parties by creation date.

Common mistakes when comparing against Oracle’s own reports:

• Counting accounts instead of parties. Manage Customers (Receivables) counts customer accounts; this card counts parties. One party can hold many accounts. Match the level before reconciling.
• Counting sites or contacts. A new party often arrives with multiple ship-to sites and contacts created on the same day. Those are not separate parties. A report keyed on sites will overstate dramatically.
• Ignoring party type filters. If your implementation creates internal or one-time parties for non-customer purposes, an unfiltered report counts them. The card counts the party types configured as customers.

Why our number may legitimately differ from Oracle’s reports:

Reason	Direction	Why
Party vs account vs site level	Oracle report often higher	This card counts parties. Account- and site-level reports count more rows per new party.
Bulk data load timing	Either	A migration or marketplace import creates many parties on one date. The card and a creation-date report should agree, but a spike can be onboarding noise, not acquisition.
Party type inclusion	Either	Internal, one-time, or prospect parties may or may not be in scope. Align the type filter.
Sync timing	Small	Card refreshes on the Fusion REST API cadence; a party created in the last few minutes appears at the next sync.
Merge and de-duplication events	Card lower	TCA party merges collapse duplicates. If a merge runs in-period, the net new count can fall below the raw creation count.

Known limitations / merchant FAQs

What is a Party in Oracle Fusion, exactly? A Party is the master entity in Oracle’s Trading Community Architecture (TCA): the real-world person or organisation you do business with. Customer accounts, sites, and contacts hang off the party. This card counts the party, the top-level entity, created in the window, not the accounts or sites beneath it.

Why count parties rather than customers or accounts? Because the party is the single source of truth for an entity in Fusion. Counting accounts double-counts a B2B customer that holds several accounts; counting sites over-counts further. The party count is the cleanest measure of genuinely new business entities entering the master.

A bulk import created thousands of parties overnight. Is that real growth? No. A spike of that shape is almost always a data migration or a marketplace bulk load, not organic acquisition. The card faithfully reports the records created, but you should read a sudden 10x move as an onboarding event and confirm against your load schedule before treating it as growth.

Does creating a party mean the customer has bought anything? No. A party can be pre-loaded for a contract that has not yet activated, or created speculatively. To see who actually transacted, pair with Active Customers.

How does the 30D vsP comparison handle a short or partial prior period? The card compares the trailing 30 days against the immediately preceding 30 days. Both windows are full 30-day spans, so the comparison is like-for-like; there is no partial-period distortion unless your Oracle instance only has fewer than 60 days of party history.

Do party merges reduce the count? Yes, net of merges. If Customer Data Management runs a de-duplication merge in the period, the surviving party stands and the merged duplicates are collapsed, so the net new count can be lower than the raw creation count. This is correct: a merged duplicate was never genuinely new.

Are Person parties (DTC individuals) included? Yes, where the implementation creates Person-type parties for individual consumers. Pure B2B implementations may only create Organization parties. The card counts whichever party types are configured as customers.

Differences vs NetSuite or Salesforce customer creation counts? NetSuite has a single Customer record; Salesforce has Account and Contact. Oracle’s TCA separates the Party (real-world entity) from the Account (commercial relationship) from the Site (location). This card counts at the Party level, which is the cleanest comparison to a NetSuite Customer or a Salesforce Account, though the underlying data model is richer. Vortex IQ supports all three.

---

Tracked live in Vortex IQ Nerve Centre

New Party Records (30d) is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.