How can I handle the ERP to carrier API handoff in our order-to-cash process?

[Aubrey_W]

I’ve been mapping out our order-to-cash cycle and hit a wall trying to figure out where to put the actual handoff from our ERP to the shipping carrier’s API. The process feels clunky because the invoice generates before we even have a tracking number, which creates confusion for accounting. I’m not sure if we should build a custom middleware or if there’s a simpler way to handle this integration point.

[JacobEM]

Yeah we hit the same wall. invoice went out before tracking was available, which made reconciliations a mess. We changed the flow so the carrier call happens earlier and the invoice stays in a pending state until the tracking shows up, then it finally prints or posts. It shaved some confusion for accounting, but it wasn’t a magic fix.

[StellaW]

I wandered into a custom middleware idea and felt it was overkill. We ended up mapping the ERP handoff to the carrier response and letting the invoice update after the tracking comes back. The handoff point now sits at the API response, not at the order create.

[BrianR]

Are we sure the real problem isn’t something else, like how the data for the invoice is sourced? Maybe the bottleneck is data quality, not the handoff story?

[Michael_M]

I tried a tiny script that pushed the tracking number back into ERP and reissued the invoice once it arrived. It helped a little, but when the carrier API lagged or failed, we ended up with sync issues and abandoned the approach in the end.