EDI Integration
Centra closes an order only once its webhook tells it the checkout session completed, and if a cancellation reaches the payment processor and that request fails, Centra's own order record moves on anyway, logging a warning and a payment history entry behind it. A wholesale purchase order dropped into that same order object inherits whatever price the storefront applies by default, unless the buyer's account terms arrive with it first. Get that wrong and the invoice goes out priced for a browser, not a trade account.
A remittance deduction rarely explains itself on its own. It shows up against one of five things: a price that didn't match the invoice, an acknowledgement that landed late, an ASN that missed the cutoff or broke the carton labelling rule, or a routing guide nobody checked before the carrier collected. Each one traces back to a step inside Centra that either fired on time or didn't.
Three things need to be in place before a wholesale purchase order can price correctly inside Centra and leave as a clean ASN. None of them are optional extras, they are what stops the first order landing at the storefront's own price.
Seven documents carry a wholesale order from the buyer's purchase order to the invoice that gets paid. Each one lands somewhere specific inside Centra, and each one can go wrong in its own way.
It lands as an order record the same way any checkout order would. Nothing inside Centra tells it to price against the buyer's account terms instead of the storefront default, so that mapping has to be set up before the PO arrives.
Built from whatever the warehouse marks as fulfilled against that order. If the fulfilment event lags behind Centra's own confirmed order state, the ASN goes out late or against the wrong line.
Because Centra carries a cancellation through even when the request to the payment processor fails, a change has to be checked against the payment history entry, not just the order's new status.
Sent back once the 850 or 860 has been read inside Centra. A missing 997 doesn't stop the order, but it leaves the partner unable to tell whether anything landed at all.
Pulled from whichever source feeds the order object its inventory figure, not from a cached storefront count. If two systems write stock into Centra, the advice is only as good as the last one that wrote.
Raised off whatever figure sits on the order line. If the buyer's terms never reached Centra before the order priced, the invoice carries the storefront figure forward, and that's what the remittance comes back against.
Only goes out once Centra's own order state is confirmed, which depends on the webhook that finalises the checkout session. If that signal is late, the acknowledgement is late behind it.
Each document depends on the one before it having reached Centra's order record correctly, not just having arrived.
Centra finalises an order from a webhook event, not from a generic status field, so the platform's own record of 'confirmed' depends on that signal arriving intact. Cancel a wholesale order while the payment processor can't be reached, and Centra will still mark it cancelled, logging a warning rather than stopping the process. That gap between what Centra believes happened and what the processor actually did is exactly where a purchase order's pricing and acknowledgement need checking, not assumed.
Once a wholesale account is trading through Centra, four things get checked every week rather than assumed. Each one is a point where the platform's own record can quietly drift from what actually happened with payment or stock.
Checking that the session-completed signal reached Centra for every order before anything downstream, pricing, acknowledgement, invoice, treats it as confirmed.
Watching for orders Centra marked cancelled while the request to the payment processor actually failed, so finance isn't working from a record the processor never agreed with.
Matching the advance ship notice to what the warehouse actually marked fulfilled, not to what Centra's order status implies on its own.
Confirming the invoice line carried the buyer's negotiated price forward rather than whatever figure the storefront would have shown a browser.
No. That provider is handling payment reconciliation on the checkout side, which is a different job from pricing a wholesale purchase order and filing the ASN and invoice against it. Cogent² can run that EDI work alongside them without touching what they already do.
The buyer's account terms and negotiated price list, handed over before trading starts, plus a contact who can confirm what counts as shipped for the ASN. Without the terms in hand, the order prices the way any checkout order would, at the storefront's listed figure.
Cogent² handles the change on the mapping side. Nobody on the brand's finance or sales team needs to go into Centra to alter how the acknowledgement is built when the partner's requirement moves.
Yes, the ASN is built from the shipment event itself, not from Centra's webhook timing, so a confirmed fulfilment can move straight into the ASN build. The watch point runs the other way, a webhook that's late or missing can hold up the order record before shipment even starts.
No. That configuration gets set up once as part of getting the account trading, and Cogent² handles the mapping and monitoring that keeps purchase orders, ASNs and invoices moving afterwards. It doesn't mean adding a developer to the brand's payroll.
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.
We use essential cookies to keep this site secure and working. We do not run advertising or analytics tracking. You can accept optional cookies or keep only the essentials. See our Cookie Policy.
