Month-end cost explained
- Read-only connection to your systems
- One plant · one product family · one close
- Comparison · contribution · evidence
- Starts in 4–6 weeks
On top of your ERP, the cause, the amount and the evidence of a cost change land on one screen.
The cause used to arrive after the decision. We move it in front of it.
Start with one plant, one product family and one month-end close — in 4–6 weeks.
A number or an assumption changes
The allocation basis moved, the material master went stale, or the calculation lives only in someone’s head.
Why it changed doesn’t reach you before the decision
There is nowhere to trace when and how a rule changed, so confirming it takes days.
Price, cost and orders change without knowing the cause
The same wrong saving repeats, and a correction report follows.
Signal
Once the close is done, how much each product family moved sits on one screen.
You don’t read all of it — only what the rules flagged.
| Product family | Cost change · vs last month | Size of move | Unit cost | Cost ratio (ref.) | Verdict · top driver | |
|---|---|---|---|---|---|---|
| 1 | +KRW 154.0M | KRW 16,915/kg+KRW 1,539 | 68.4%+4.3%p | Over thresholdRaw-material price | ||
| 2 | +KRW 70.19M | KRW 16,149/kg+KRW 710 | 69.5%+3.5%p | Publication blockedKRW 45,000,000 unexplained | ||
| 3 | +KRW 68.3M | KRW 16,263/kg+KRW 732 | 72.1%+3.8%p | Over thresholdRaw-material price |
Click a row and the Decision Brief below switches to that family.
This is the real product screen. The figures are fictional data, and every number on it is the result of SQL run against the connected sources.
Explanation · evidence
Pick a product family and the cost change splits by factor. Each line carries its formula and the owning department, and the screen checks that the total matches the cost change.
| Why it changed | Amount | Share | Cost-ratio effect | Owner | Verified |
|---|---|---|---|---|---|
| KRW 83,504,500 | +53% | +2.3%p | Purchasing | Verified | |
| KRW 49,495,500 | +33% | +1.4%p | Production | Provisional | |
| −KRW 47,873,684 | -30% | −1.3%p | Production control | Provisional | |
| KRW 36,873,684 | +23% | +1.0%p | Production | Provisional | |
| KRW 32,000,000 | +21% | +0.9%p | Cost accounting | Provisional | |
| Total | KRW 154,000,000 | +100% | +4.3%p | Checked against the cost change | |
The total reconciles. The five axes add up to KRW 154.0M — the same as the cost change. The tolerance is ±0.05%p; beyond it we do not invent an “other” bucket, we simply do not publish the Brief.
SELECT material_code,
SUM(qty_kg * (unit_price
- prev_unit_price)) AS contrib
FROM purchase
WHERE period = ? AND product_group = ?
GROUP BY material_code
ORDER BY contrib DESCClick an axis and its evidence changes — currently “Price axis”.
A candidate cause is not a verdict. This product answers as far as the axis points; the judgement after that is yours.
This isn’t a tool that answers once and stops. Evidence and decisions stay in the same place, so this month’s judgement is where next month starts.
Signal
When cost or margin moves unlike it usually does, we catch it first — before anyone opens the month-end close.
Explain
What contributed and by how much, split by item, process and department — with the comparison base and the calculation alongside.
Decide
Every candidate cause carries a drill-down, a formula and a source. Your team checks it on the spot and moves to the decision.
Act
For a confirmed cause we propose what to do next, and record the action a person picks. Whether it happens is a human approval.
Learn
What was decided, on what evidence, and how it turned out — all kept. Next month the same question starts from that record.
In the Act and Learn stages the system proposes and records. It does not act for you, and approval stays with a person.
We only read from them. That means no system replacement and no migration to get started — and a source that isn’t connected is shown as not connected.
The edge of coverage — this is as far as the system goes. MES and BOM exist as nodes in the definition file but are not loaded. So yield broken down by process and lot and attributing purchase vouchers to a product family are not answered here. We do not fill them in with estimates.
It goes as far as explaining a closed set of books. Being read-only keeps the review short, and there is nothing to roll back.
We don’t start by assuming tidy data. Finding out when the allocation basis changed and how stale the master data is, is the early work. If clean data were the entry price, this problem would never get solved. If tidying the data and the decision rules is itself what you need right now, that’s a different engagement — the plant diagnostic covers it.
It is built to stay silent when it is not sure. The five-axis breakdown has to match the actual cost change within ±0.05%p before a Brief goes out. When it cannot, it does not invent an "other" bucket; that month simply gets no Brief. Every answer that does go out carries its cause, amount and evidence, so your people can check it on the spot.
None. We only read your existing systems; nothing new has to be entered. There will be a few things to confirm with your people while we align the assumptions behind the calculation.
Permissions
An executive and an analyst look at the same numbers but not the same screen. What is not shown is specified just as carefully as what is.
| Role | Scope | What the screen shows | What stays hidden |
|---|---|---|---|
| CFO · finance executiveChooses which of the five families to dig into | All families | The list is the hero · Brief down to the summary layer · validation shows the gate verdict only | Technical detail — residuals, SQL counts, gates, pack versions — opened only when something looks off |
| Cost accountantBuilds the explanation and defends the numbers | All families | Every layer — axis table, SQL, vouchers, gates, open items, glossary alignment, ad-hoc queries | Nothing. If this role can’t see the evidence, the product doesn’t work |
| Division head · plant managerAnswers why cost moved in their own product family | Frozen food only | Ownership and the written explanation at the top · one row in the list · evidence collapsed | Every other family · the validation screen · vouchers and SQL · ad-hoc queries · setup screens |
| FDE · ontology ownerConnects the customer ERP to the definition file and sets the detection rules | All families | Every layer + golden set · QA scoring + Ontology Studio + workflow setup + operations and admin | Nothing. Early in a rollout this role is the only user |
Role names and scopes come from the definition file. Where your organisation calls them something else, we use your words.
You don’t have to commit to a company-wide rollout first. Start by seeing whether one product family’s close produces an answer.
Fix the scope
One plant, one product family, one month-end close. The narrower the cut, the sooner the answer.
Connect the data
We connect your existing systems read-only and write down where each value comes from.
Align the rules
We check the allocation rules and when master data was last updated, so the calculation starts from the right assumptions.
Check the explanation
We answer real month-end questions with comparison, contribution and evidence — and confirm it with your team.
Five questions are enough to tell whether now is the right time to start. We don’t ask for your contact details.
1 / 5
Where this goes
That’s the direction we’re heading. What a contract promises today, though, is the month-end cost explanation described above — no more. The rest widens step by step as the evidence accumulates.
Before you start
Next step