Fra B/L til detentionfaktura: hvor dagene forsvinder

Et konnossement (B/L) og en detentionfaktura (D&D) ligner to helt adskilte dokumenter — det ene udstedes ved lastning, det andet dukker op uger senere, længe efter containeren er losset. I virkeligheden er det samme rejse, blot set fra to forskellige dokumenters perspektiv. Og netop mellem dem, ved punkter som intet af dokumenterne viser hver for sig, forsvinder som regel de dage, der senere faktureres.

Containerens rejse i fire punkter

B/L udstedes i lastehavnen — det angiver forventet ankomsttid (ETA), rederi og rute. Dette er det første punkt, hvor tidsregistrering kunne begynde, men som regel gør ingen det, fordi B/L på dette stadie kun bruges som ejendoms- og transportdokument, ikke som startpunkt for et ur.

Det andet punkt er den faktiske losning i destinationshavnen. Det er fra netop denne dato — ikke fra ETA, som ofte afviger flere dage fra virkeligheden — at de fleste rederier begynder at tælle den aftalte fri tid. Registrerer en virksomhed ikke denne dato med det samme, men får først kendskab til den ved fakturaens modtagelse, har den allerede mistet muligheden for at kontrollere, om beregningen startede på det rette tidspunkt.

Det tredje punkt er, når modtageren afhenter containeren fra terminalen (gate-out). Mellem losning og afhentning går der ofte dage — på grund af terminalkapacitet, toldprocedurer eller blot logistikplanlægning — men uret for fri tid kører allerede da, uanset årsagen.

Det fjerde punkt er returneringen af den tomme container. Netop denne dato, sammenlignet med losningsdatoen, bliver grundlaget for D&D-fakturaen. Og netop her opstår afvigelsen oftest: returdatoen angivet på fakturaen kan afvige fra den faktiske, fordi terminalens registreringssystem og rederiets faktureringssystem ikke altid er synkroniserede.

Hvorfor disse fire punkter sjældent ses samlet

Problemet er ikke, at disse data ikke findes — de er spredt mellem B/L, terminalens gate-registreringer og rederiets faktura, som regel i forskellige formater, forskellige systemer, nogle gange endda forskellige afdelinger i samme virksomhed. Indtil nogen manuelt sætter alle fire datoer i én række, forbliver en afvigelse mellem dem usynlig — fakturaen bliver simpelthen betalt, fordi kontrollen ville koste mere tid, end den er værd.

Hvor de to datastrømme mødes

Cargo Intelligences sømodul udtrækker automatisk containernummer, rederi, rute og forventet ankomstdato fra B/L-dokumentet allerede ved lastning. D&D-revisionen kontrollerer, om den senere modtagne detentionfaktura matcher kontraktvilkårene og de faktiske terminaldata. Når disse to datastrømme mødes — B/L-data fra begyndelsen, fakturakontrol fra slutningen — opstår muligheden for at se hele containerens rejse ét sted, i stedet for at håbe på, at nogen manuelt sammensætter fire separate punkter til én linje.

Dette fjerner ikke behovet for reelle terminal gate-in/gate-out-data — det indeholder B/L-dokumentet ikke i sig selv. Men det betyder, at halvdelen af rejsen allerede er tilbagelagt automatisk, før fakturaen overhovedet opstår.