Flowment
Freight-cost platform: import and auditing of carrier invoices, pricing against the customer's own agreements, discrepancy detection and re-invoicing for 3PLs. Built at Redi AS.
Companies that ship a lot of goods rarely have a single freight agreement. They have one for parcels, one for pallets, one for express, and each is negotiated separately. When the carrier's invoice arrives at the end of the month, it often doesn't match what was agreed: the volume was miscalculated, a surcharge has appeared, a discount threshold was missed by two shipments. Someone has to check it, shipment by shipment, and then pass the freight on to the end customer where it belongs. An invoice with a thousand lines doesn't get checked by hand.
Flowment is the platform that does that job. I work on it as a full-stack developer at Redi AS, for Flowment AS, which offers it in two models: an administration layer on top of the customer's own freight agreements, and resale of Flowment's own negotiated agreements to customers who don't have the volume to negotiate themselves. Both models have to price shipments against the agreement, check for discrepancies against the carrier's invoice, calculate commission for partners and distribute margin.
What the platform does
The chain starts with importing and parsing carrier invoices. Each shipment is priced against the customer's own pricing rules, discrepancies are flagged, the cost is allocated to the right end customer, and the invoice basis is passed on to the accounting system. Around the core sit customer invoicing, claims and re-invoicing for 3PL customers, who invoice freight on to their own customers.
The platform has separate portals for owner, customer, partner and 3PL, a native iOS app against the same backend-for-frontend, and an internal operations system alongside.
What I've put the most emphasis on
Access is enforced in the database, not in the queries. The system is multi-tenant, and a bug in the application layer must not be able to leak data between customers. Cost price is masked at column level in the database, not in the application, so margins can't reach the wrong recipient no matter which code path asks for them.
Idempotent import. The same shipment can come back from the carrier as a duplicate, as a correction or as a repricing, and at row level the three look identical. The import tells them apart using a content hash plus document context, so a file can be run in twice without producing a double invoice basis.
Integrations with signature-verified webhooks. PostNord for shipment data, PowerOffice Go and Tripletex for accounting, the Brønnøysund Register Centre for company lookups, Vipps for payments, Signant for signing and Resend for email.
Background jobs that tolerate failure. Jobs are serialized with database locks, and a dedicated worker holds a lease on the task with attempt counting and exponential backoff. Nightly runs match every invoice line against the platform's own calculation, and discrepancies above the threshold land in a queue that the operators go through the next morning.
Tested against a real database. Domain logic, integrations and access rules have a broad test suite, with dedicated runs against a real PostgreSQL so that isolation between customers is verified where it is actually enforced.
Stack and operations
Next.js 15 with App Router and Server Components by default, React 19 and TypeScript. Supabase on PostgreSQL, self-hosted on Hetzner via Coolify with data stored in the EU, and Drizzle for schema and migrations. Trigger.dev for scheduled jobs, GitHub Actions for CI/CD, and Swift with SwiftUI on iOS. Money is stored and calculated as decimals all the way through, never as floats. It's the kind of discipline that is no fun to clean up afterwards.
Status
Under active development. The pricing, margin and commission engine, invoice import and discrepancy checking are in place, and the portals and the iOS app are being developed further in parallel.
This text is machine translated and has not been reviewed yet.