ERP / operations
Ship = sales
¥2,086,000
Includes uninvoiced. Transfers count as issues. Stores still use old codes. Returns wait for warehouse confirm before reverse.
The same day’s “sales” failing to match across three systems is not a small rounding error. It sends replenishment to the wrong waterline, pays bonus on the wrong margin, and loses the ticket when a customer complains. More systems raise the risk, not because software is expensive, but because nobody named which number is the operations definition.
Finance ledger
Invoice = revenue
¥1,742,500
Excludes uninvoiced. Free goods sit in a separate account. Customers by tax ID, not store. ¥340k below operations. The weekly meeting starts there.
Store POS
Collect = performance
¥1,958,300
Includes stored value and punch-card redemptions. Stored value is not finance revenue. Store-manager bonus uses this column and never agrees with finance.
The risk is not “we are off by a few hundred thousand.” It is that no written rule says who each column serves, and which column the operations dashboard recognizes. Without a rule, every new chart copies the conflict again.
Layer one is delayed decisions. Half the weekly meeting matches tables. Real stockouts and slow movers get pushed after. The path gap with vs without a dashboard, see With vs without an operations dashboard: how the decision path changes. Layer two is ownership vanishing: operations blames finance’s definition, finance blames unclosed orders, stores say “POS is just like that.” Without master data you cannot even agree whether “Nanshan” is one store; see Without master data, visualization lies.
Layer three is API debt. Each new system gets a private export. Swap finance software or add a mini program and every chart reconnects. When systems keep multiplying, standardize APIs before you draw; see More systems connecting: standardize APIs or draw charts first. Once APIs hold, the next chart is faster; see Once APIs are standardized, the next chart is faster.
Layer four is compliance and audit. Bonus, franchise settlement, and tax sampling may all replay “the sheet from that day.” Separate math cannot be reproduced. Finance-only BI hides the fight inside accounts; see Finance-only BI, with no business documents: what happens. In a chain, unclear roll-up rules make HQ chase the wrong store; see After stores roll up, how HQ watches outlier stores.
DaXi’s method is direct: put the three to five conflicting KPIs on the table, write how each system calculates, which set operations recognizes, and which reconciling table takes the difference. Mid-size companies do not need a big platform for this; see Do mid-size companies have to buy a data platform. To fold “each system calculates its own” into one set you can challenge, go to the Data service page and send screenshots of the three number sets.
Source systems may keep their own math. They must map to the operations definition
Allow a system to keep its operational definition, but map it. Do not treat “does not match” as a permanent state. Differences need accounts, not verbal estimates.
Before device counts, energy, or station passes enter a dashboard, align clocks and primary keys. A wrong clock or work-order number makes a shop-floor screen scarier than Excel.
Do not paper over a conflict with mental math in the meeting. A ¥340k gap is an uninvoiced window, stored value, or a transfer. The reconciling table must point to a document set, not “probably timing.” If you cannot open the set, you are still calculating separately. The dashboard must pick one operations column and sign it; see Why an operations dashboard is not optional. A shop-floor screen should consume work orders and output, not three sales figures at once; see How a shop-floor screen keeps crews out of the office.