Why these reports don't exist natively in your ERP
ERP systems are built to capture and process operational transactions accurately. A sales order, a goods receipt, a GL journal entry. They are not built to structure those transactions into management-ready analytics. The data for every report on this list exists in your ERP. But it lives in operational tables organized by transaction type, not by management question.
Building these reports requires joining those tables in ways the ERP does not do by default, applying consistent definitions across entities, and normalizing master data so that the same customer, supplier, or product is recognized across every record. In a multi-ERP environment, each of those steps must happen across different schemas, different chart of accounts structures, and different naming conventions simultaneously. None of this is impossible. It is just not what ERPs are designed to do on their own.
Each report below shows: what it contains, why the ERP does not build it automatically, and which decisions it enables. Each maps to one or more Marquis IQ modules that surface it from your existing ERP data without replacing or disrupting operational systems.
The 7 reports
Revenue, COGS, gross margin, operating expenses, and EBITDA for every legal entity and consolidated across all of them, on a single chart of accounts, with intercompany transactions eliminated and consistent period definitions applied across all ERP instances.
Each ERP instance uses the entity's own chart of accounts. Account code 4100 means revenue at one plant and service income at another. Intercompany sales must be identified, matched, and eliminated. Period close dates differ across plants. Currency conversion needs consistent FX rates applied at the same point. No single ERP instance can see across the others.
Gross margin in dollars and percentage for every customer account, product line, and plant. Period-over-period change attributed to cost side movements (labor, material, burden) and price side movements (list price, price list adjustments, volume slope discounts). See the complete gross margin analysis framework for how each component is decomposed.
Linking revenue by customer to cost of goods requires joining the sales order tables to production or work order tables to standard cost tables. Each connection point has exceptions: partial shipments, rework, cost roll timing differences. Across multiple ERP schemas, this join requires a normalized data layer before it produces reliable numbers.
AR aging by customer with dispute flagging and days sales outstanding trend. Inventory days on hand by category and by plant. AP aging by supplier with days payable outstanding trend. Cash conversion cycle as an integrated metric, DSO plus DOH minus DPO, tracked period over period across all entities.
AR, inventory, and AP live in separate ERP modules, often with different aging bucket definitions and different period-end cutoffs. Combining them into one dashboard requires a unified customer and supplier master. Without it, the same customer appearing under different IDs inflates or fragments the AR aging. The cash conversion cycle calculation requires consistent period alignment across all three components.
Revenue change decomposed into three non-overlapping components: price effect (did we charge more or less per unit?), volume effect (did we sell more or fewer units?), and mix effect (did we shift toward higher or lower revenue products?). A waterfall chart by product line, customer, or plant showing exactly what drove the period change. See the full PVM analysis framework for methodology and a worked example.
PVM requires transaction-level quantity and price data for both periods, joined through a consistent product hierarchy. After SKU consolidations, customer account renaming events, or ERP migrations, the historical join breaks and the bridge produces inaccurate attribution. Multi-ERP environments require matching SKUs and customer accounts across systems before the analysis is coherent.
Customer on-time delivery rate by plant, product line, and customer, measured against the original customer-requested date rather than any internally revised promise date. Production attainment: actual output versus planned by work center. Fill rate, backorder depth, and premium freight spend as indicators of service level cost.
Accurate OTD requires comparing the ship date to the original customer-requested date, not the most recent promise date after internal revisions. ERPs frequently record promise date updates, which makes OTD look better than the customer's actual experience. Multi-plant aggregation requires a unified order identity across systems. Production attainment definitions vary across ERP configurations and plants.
Total supplier spend by category, plant, and period with trend. Purchase price variance by root cause: material inflation, spot buy premium, catalog drift, and negotiated recoveries. Pricing compliance rate by supplier. Payment terms captured versus negotiated. See the full ERP procurement analytics framework for each signal in depth.
Multi-plant spend consolidation requires a unified supplier master. Without it, the same physical supplier appearing under different IDs at different plants shows up as unrelated vendors and the total spend relationship is invisible. PPV by root cause requires joining PO standard prices to receipt prices to contract prices, which live in different tables and require contract terms to be loaded alongside transaction data.
Days on hand for every stocked SKU by plant, compared to forward demand from open orders or historical usage rates. Slow-moving stock classified by coverage ratio: SKUs with 90-plus days of supply flagged regardless of total dollar value. Working capital tied up in excess inventory quantified at the SKU level with trend to show what is building versus burning.
DOH by SKU requires linking current on-hand quantity to a forward demand estimate. That demand may come from open orders, planned production, historical usage, or some combination, and ERPs define and store it differently. Multi-plant SKU analysis requires matching item numbers across systems, which breaks after part renumbering events and acquisitions where the same physical part carries different item IDs at different plants.
How Marquis IQ surfaces all seven from your ERP data
Each of the seven reports above maps to one or more Marquis IQ modules that connect directly to your ERP, normalize the data into a consistent management-ready structure, and deliver the report without requiring your team to rebuild it each period. The underlying ERP keeps running all operational processes unchanged.
Marquis IQ connects to every ERP in your portfolio, enriches the master data so customers, suppliers, and items are recognized consistently across plants, and builds the analytical layer that surfaces these reports automatically each period. Each IQ module handles its domain: Finance IQ for consolidated P&L and working capital, Pricing IQ for gross margin and PVM, Operations IQ for OTD and production attainment, Procurement IQ for supplier spend and compliance, Inventory IQ for SKU-level coverage.