ERP integration for comex: orders, invoices, and finance in sync

The gap between comex and the ERP

Most Brazilian importers run two worlds. The comex team works in one set of tools to handle classification, licenses, and customs. The finance team works in the ERP to handle purchase orders, payments, and the general ledger. Between them sits a gap, and that gap is filled with manual work.

Someone rekeys the purchase order into the customs system. Someone copies the landed cost back into the ERP. Someone reconciles the supplier invoice against the DUIMP by hand. Every one of those steps is a chance to make an error, and every error costs time to find and fix.

What double entry actually costs

Rekeying is not just slow. It breaks the numbers.

• A purchase order typed twice can hold two different totals
• A landed cost calculated in a spreadsheet never reaches the ledger, so the product cost in the ERP is wrong
• A supplier invoice paid in the ERP does not link to the customs entry, so reconciliation is guesswork
• The FX rate used for the payment differs from the rate used for the customs value, and nobody notices until the audit

The result is a set of books that does not match the customs record. When the tax authority asks how the customs value ties to the payment, the answer takes days to assemble.

What integration puts in sync

Connecting the comex system to the ERP means the same data lives once and moves between the two.

| Data | Starts in | Flows to | |---|---|---| | Purchase order | ERP | Comex system | | NCM and classification | Comex system | ERP product record | | Landed cost | Comex system | ERP as product cost | | Supplier invoice | ERP | Matched to customs entry | | FX contract | Finance | Comex cost basis |

Each piece is entered once, by the team that owns it, and the other side reads it. No rekeying, no copy and paste, no two versions of one number.

The landed cost link

The single most valuable connection is landed cost. The comex system knows the real cost of goods after II, IPI, PIS, COFINS, ICMS, freight, and insurance. The ERP needs that number to value inventory and set margins.

When the two are connected, the landed cost flows straight into the product record in the ERP. Inventory is valued correctly. Pricing is based on the true cost. And finance closes the month without a spreadsheet reconciliation.

You still want to model that cost before the goods arrive, which is where an import cost calculator fits at the planning stage, feeding a number the integration later confirms against the actual customs entry.

How Kadmoon builds the connection

Off the shelf comex tools export a file and hope the ERP reads it. A bespoke integration is built for your specific ERP and your specific process.

At Kadmoon we connect the comex system to the ERP so the data flows both ways, cleanly, with a record of every exchange.

• Purchase orders read from the ERP, so the comex team works from the real order, not a copy
• Landed cost pushed back into the ERP as product cost, automatically, per SKU
• Supplier invoices matched to the customs entry, so reconciliation is done, not deferred
• FX contracts shared across both systems, so the payment and the customs value use one rate
• A log of every transfer, so an audit question has an answer in seconds

The point is not the technology. The point is that a person stops typing the same number into two systems and stops chasing the difference when the two disagree.

Start with the biggest leak

You do not have to connect everything at once. Find the step that eats the most time and causes the most errors, usually the landed cost transfer or the invoice reconciliation, and connect that first. The time saved on one flow pays for the work and proves the case for the next.

Get the comex system and the ERP talking, enter each number once, and the whole import operation runs on books that finally match the customs record.