Flowment
Plattform for fraktøkonomi: import og kontroll av transportørfakturaer, prising mot kundens egne avtaler, avviksdeteksjon og viderefakturering for 3PL. Bygget hos Redi AS.
Bedrifter som sender mye gods har sjelden én transportavtale. De har en for pakker, en for paller, en for ekspress, og hver er forhandlet separat. Når fakturaen fra transportøren kommer i slutten av måneden, stemmer den ofte ikke med det som ble avtalt: volumet er feilberegnet, et tillegg har dukket opp, en rabattgrense ble bommet på med to sendinger. Noen må kontrollere det, sending for sending, og deretter sende frakten videre til sluttkunden der den hører hjemme. En faktura med tusen linjer kontrolleres ikke for hånd.
Flowment er plattformen som gjør den jobben. Jeg jobber på den som fullstack-utvikler hos Redi AS, for Flowment AS, som leverer den i to modeller: et administrasjonslag oppå kundens egne transportavtaler, og videresalg av Flowments egne fremforhandlede avtaler til kunder som ikke har volum til å forhandle selv. Begge modellene må prise sendinger mot avtalen, kontrollere avvik mot transportørens faktura, regne provisjon til partnere og fordele margin.
Hva plattformen gjør
Kjeden starter med import og parsing av transportørfakturaer. Hver sending prises mot kundens egne prisregler, avvik flagges, kostnaden fordeles på riktig sluttkunde, og fakturagrunnlaget går videre til regnskapssystemet. Rundt kjernen ligger kundefakturering, reklamasjon og viderefakturering for 3PL-kunder, som fakturerer frakt videre til sine egne kunder.
Plattformen har egne portaler for eier, kunde, partner og 3PL, en native iOS-app mot samme backend-for-frontend, og et internt driftssystem ved siden av.
Det jeg har lagt mest vekt på
Tilgang håndheves i databasen, ikke i spørringene. Systemet er multi-tenant, og en feil i applikasjonslaget skal ikke kunne lekke data mellom kunder. Kostpris maskeres på kolonnenivå i databasen, ikke i applikasjonen, slik at marginer ikke kan nå feil mottaker uansett hvilken kodevei som ber om dem.
Idempotent import. Samme sending kan komme tilbake fra transportøren som duplikat, som korreksjon eller som reprising, og på radnivå ser de tre like ut. Importen skiller dem ved hjelp av innholdshash pluss dokumentkontekst, slik at en fil kan kjøres inn to ganger uten å gi dobbelt fakturagrunnlag.
Integrasjoner med signaturverifiserte webhooks. PostNord for sendingsdata, PowerOffice Go og Tripletex for regnskap, Brønnøysundregistrene for selskapsoppslag, Vipps for betaling, Signant for signering og Resend for e-post.
Bakgrunnsjobber som tåler feil. Jobbene serialiseres med databaselåser, og en egen worker holder lease på oppgaven med forsøkstelling og eksponentiell backoff. Nattlige kjøringer matcher hver fakturalinje mot plattformens egen beregning, og avvik over terskel havner i en kø som operatørene går gjennom morgenen etter.
Testet mot ekte database. Domenelogikk, integrasjoner og tilgangsregler har en bred testsuite, med egne kjøringer mot en ekte PostgreSQL slik at isolasjonen mellom kunder verifiseres der den faktisk håndheves.
Stack og drift
Next.js 15 med App Router og Server Components som standard, React 19 og TypeScript. Supabase på PostgreSQL, selvhostet på Hetzner via Coolify med datalagring i EU, og Drizzle for skjema og migrasjoner. Trigger.dev for planlagte jobber, GitHub Actions for CI/CD, og Swift med SwiftUI på iOS. Penger lagres og regnes som desimaltall hele veien, aldri som flyttall. Det er den typen disiplin som ikke er morsom å rydde opp i etterpå.
Status
Under aktiv utvikling. Pris-, margin- og provisjonsmotor, fakturaimport og avvikskontroll er på plass, og portalene og iOS-appen utvikles videre parallelt.