Key takeaways

  • Monitor ERP already has two built-in routines linking production to finance: PIA value for the books, and post-calculation for planned versus actual cost.
  • The underlying definitions drift easily: order status, per-unit versus whole-order figures, and FIFO prices that can change retroactively once a supplier invoice is matched.
  • The optional Internal Accounting module posts manufacturing-order transactions to the general ledger natively and produces a reconciliation list against the WIP account, but only if it's activated in your installation.
  • A shared definition of 'actual cost' needs a joint owner across production and finance, with a clear cutoff for when it counts as final.
  • Connecting production data to other systems requires read permissions, explicit mapping, and reconciliation against the booked balance before a figure goes anywhere. AI doesn't replace the closing process.

Two routines Monitor already has for production and finance

PIA value calculates the accrued value of work in progress, manufacturing orders at status 3 to 5, as the basis for booking WIP at month or year-end close. It's always shown for the full order quantity, in company currency, and can run as a current snapshot or for a past date.

Post-calculation serves a different purpose: once an order or article has been reported, it compares planned cost to actual cost, per unit and in total. Planned cost is calculated as in the pre-calculation; actual cost comes from the manufacturing order log. The price can only be saved permanently at status 4 (done) or higher.

With the optional Internal Accounting module active, every manufacturing-order transaction (the WIP value) posts straight to the general ledger, worked hours book to the income statement by department, and calculation differences track by product or order. The module also produces a reconciliation list tying WIP back to the booked balance on the WIP account, per order with drill-down.

Where the definitions start to diverge

Order status decides what's counted. PIA value spans status 3 to 5; post-calculation only locks a price at status 4 or above. Mix statuses in one report without saying so, and two people asking the same question get two different answers.

PIA value always shows the whole order quantity; post-calculation can show per unit or total. It's an easy mistake to compare a per-unit figure against an order-level one and misjudge margin.

FIFO valuation is built from historical stock log entries, and a purchase order's price updates retroactively once the supplier invoice matches the goods receipt. So the 'actual cost' of a manufacturing order can still move after the order was reported done on the shop floor. A figure that looks final in production isn't final until invoice matching catches up.

A concrete workflow: from manufacturing order to a shared margin figure

Take a representative scenario: a manufacturer wants monthly gross margin by product family, reconciled to the books. Step one is connecting Monitor and wherever bookkeeping actually lives, Monitor's own accounting module or a separate finance system, as distinct sources, with read access to the order register, the manufacturing order log, and the chart of accounts.

Step two is agreeing the definition before computing anything: which order status counts as 'done' for the margin calculation, whether actual cost is per unit or per order, and when after invoice matching a cost is final rather than provisional. That definition should be owned jointly by production and finance, not reinvented inside each analysis.

The calculation itself then runs as an explicit query or code reading straight from the sources, never a figure pasted by hand, so it can be re-run and checked. Before it reaches any report, the computed WIP total is reconciled against the booked balance on the WIP account, the same check Monitor's own reconciliation list performs when Internal Accounting is active.

This is the kind of shared foundation a platform like Ronja is built to provide: Monitor and the finance system connect as sources, the definition is stored as a governed metric with a formula, scope, and owner rather than a spreadsheet formula, and the figure is computed by a real query rather than written by a model. Which Monitor objects are reachable through a given connection still varies by installation and add-on, and needs confirming before you rely on it.

What this doesn't solve

This doesn't replace Monitor's own closing process, and it doesn't replace post-calculation or PIA value as the source of truth for production economics. A shared definition sits on top of those routines; it doesn't create a new truth.

Read permissions, data mapping, and reconciliation are necessary steps, not shortcuts. A figure never reconciled against the booked balance is an estimate, not a closing document.

Which Monitor tables and fields are actually reachable depends on the installation and which add-ons are active, such as Internal Accounting. Assume nothing about coverage until it's confirmed.

If the figures come from more than one system, say Monitor plus a separate finance system, there's added reconciliation risk: exchange rates, manual journal entries, and accruals absent from the production data have to be handled separately and can't be assumed to line up.

Checklist before connecting production and finance

Confirm whether the Internal Accounting add-on is active in your Monitor installation. It decides whether you already have native posting and reconciliation, or whether the mapping has to be built from scratch.

Decide which order status, 3, 4, or 5, counts as the cutoff for 'done' in your margin definition, and write the decision down.

Decide whether actual cost is counted per unit or per order, and keep that choice consistent across every report meant to be compared.

Clarify when, after invoice matching, a cost counts as final rather than provisional, given that FIFO prices can move retroactively.

Confirm read access to the order register, the manufacturing order log, and the chart of accounts in both systems before building any connection.

Require that every financial figure can be traced to an explicit query or piece of code, never a number pasted in by hand.

Reconcile WIP against the booked WIP balance. Separately reconcile the revenue and cost components used for margin against the relevant accounting records before reporting the result.

Sources

Frequently asked questions

Do we need the Internal Accounting add-on for this?

No, but without it you lose Monitor's native posting of manufacturing-order transactions and its ready-made reconciliation list against the WIP account. The mapping to the general ledger then has to be built separately instead of reused.

Can AI replace post-calculation or PIA value?

No. Those routines remain the source of truth for plan-versus-actual and inventory valuation. A shared foundation combines that outcome with other systems under one traceable definition; it doesn't recompute it differently or replace the close.

Does this work with a different accounting system than Monitor's own module?

Conceptually yes: both systems connect as sources and the definition is built regardless of where bookkeeping happens. But exactly which fields are readable varies by system and needs confirming first.