ERP system development
in Irvine

Two companies can sell the same product at the same price and report different margins for it. Often the gap comes from how the ERP values stock. Costing is a setting chosen early, usually by whoever configures the item master, and then it colours every gross margin figure the business looks at for years.

The common methods are few. Standard cost assigns each item a planned cost and posts the difference between plan and actual to variance accounts. Weighted average recalculates the unit cost each time new stock arrives. First in, first out assumes the oldest units leave first, so each sale carries the cost of a specific earlier receipt. Specific identification tracks the actual cost of each serial-numbered unit. Each one answers a different question.

Standard cost suits manufacturers. Engineers set a cost per assembly from the bill of materials and routing, and the variances show where production drifted: a supplier raised a price, a line ran slower, scrap was higher. The margin on the sales report stays stable, and the story of what went wrong sits in the variance accounts. That is useful. It also means someone must review and update standards regularly, or the variances grow until nobody trusts them.

Weighted average fits distributors who buy the same item repeatedly at shifting prices. It smooths out spikes. It is simple to explain. The weakness shows when a large receipt arrives at an unusual price. The average jumps, and margins on sales that week look strange for reasons that have nothing to do with selling.

First in, first out tracks physical flow closely for perishable goods and anything with expiry dates. It needs cost layers, a record of each receipt with its quantity and price, and the ERP must consume those layers in the right order on every issue. That is more data and more computation. A custom build has to handle returns carefully, because a returned unit must go back into the right layer.

Landed cost complicates all of them. Freight, duty, insurance and handling belong in the value of the stock. Often those invoices arrive weeks after the goods. The ERP needs a way to allocate them back to receipts, by value, weight or quantity. It then needs to decide what happens to units already sold before the freight bill came in.

Changing method later is painful. Historical valuations stop matching, auditors ask questions, and reports need a clear cut-over date. So decide before migration. Run the same quarter of real transactions through two candidate methods in a test environment and compare the margin reports side by side. Show the result to finance and to sales. If they read the numbers differently, that conversation is cheaper now than after go-live.

Growth rarely stays inside one company. A holding company appears, then a separate entity for a new product line, then another that owns the equipment and leases it back. Each keeps its own books. Yet they share customers, staff, warehouses and bank relationships. An ERP built for a single entity starts to strain the moment the second one is added.

The first design decision is how entities are separated in the data. Every transaction, account balance and document number needs an entity field, and every query must respect it. Permissions follow from that. A bookkeeper for one entity may need read access to another but no right to post there. Adding the field late means touching almost every table, which is why it belongs in the first data model even if only one company exists on day one.

Intercompany transactions are where the real work lies. One entity sells goods to another. One pays a shared supplier and recharges part of the cost. Staff employed by one company work for all of them. Each of these creates two sides: a receivable in one ledger and a payable in the other. If the ERP asks people to post both sides by hand, they will drift apart. Somebody forgets. Amounts get rounded differently. Dates fall in different periods.

A better pattern generates the mirror entry automatically. When entity A invoices entity B, the system creates the matching purchase document in B, with the same amount, date and reference, and links the two. Edits on one side are blocked or propagated. A reconciliation screen lists any pair that does not match, so the month does not close with a gap nobody can explain.

Consolidation comes next. Group reports must add the entities together and then eliminate internal sales, internal balances and internal profit sitting in stock. Doing this in spreadsheets each month is slow and fragile. The ERP can tag intercompany accounts so elimination entries are proposed automatically. Finance reviews them and approves.

Currencies add a layer if entities keep books in different ones. Each entity reports in its own functional currency, while the group reports in one. The system needs rate tables, a rule for which rate applies to which balance, and a clear place for translation differences.

Shared services need a rule as well. When one team does work for everyone, decide how its cost is split: by headcount, by revenue, by time recorded. Put that rule in the system as a scheduled allocation rather than a journal someone types each month. Clear allocation keeps each entity honest, and it keeps the group view readable.