PlatformBilling & settlements
Drayage billing starts at the gate, not at month end
Detention, per diem, chassis splits and waiting time are earned on the street and lost in the office. The drayage billing software inside DrayBase is being built so that a charge is born on the move that created it, with the timestamp, the appointment and the document already attached to it. None of that is written yet, and the rest of this page is careful about the difference.
BuiltThe money primitives
What already carries money
A billing module is only as honest as the operating record underneath it. Most drayage invoices get argued down because nobody can produce the timestamp behind the accessorial. So the parts that decide whether a charge survives a phone call are the parts that got modeled first.
- Free time exposure
- Per diem and demurrage are calculated per container in calendar days of the port's time zone. The zone is an argument the calculation takes, never the machine it runs on, and it defaults to the NY/NJ market this is being built alongside — a last free day that expires on Wednesday in Newark expires on Wednesday, whatever UTC thinks. Demurrage counts only while the box is still inside the terminal: the moment it gates out that clock zeroes and per diem takes over, running until the empty comes back. That arithmetic runs on the board today.
- Rate precedence
- The daily rate resolves in order: the override on that container first, then the rate negotiated with that steamship line. Both are columns you fill in, so the number a dispatcher stares at all day is the one you actually agreed to. When neither is set the arithmetic falls back to a documented constant in the domain module — $130 a day for per diem, $200 for demurrage — and we say so rather than dress it up: a rate default you can set per carrier is not a column yet. Planned
- Revenue and cost on the load
- Every load carries revenue and estimated cost as integer cents. Money is never a float anywhere in this schema — that is a decision, not an accident, and it is why a margin figure will not drift by a penny per load until the totals stop matching.
- Driver pay per leg
- Pay lives on the move, not on the load, so a reassignment three hours later cannot quietly rewrite what the first driver earned on the first leg. The field is there. The run that rolls those legs into a weekly settlement is not. Planned
- Terms per customer
- Payment terms in days, credit limit, a billing email separate from the operations contact, and a flag for whether that customer pays without a POD attached. Aging needs all four, and they are on the record before there is anything to age.
- Chassis cost
- Daily pool cost and in-use-since sit on the chassis itself, which is exactly where a pool invoice dispute is won or lost. See chassis and pools.
- Who may touch money
- Billing and settlements are real roles with their own permission sets — invoice view, create and approve; settlement view and approve — and a dispatcher holds none of them. The matrix is explicit in code rather than scattered through the resolvers, so it can be read in one sitting.
- Document types
- Invoice, settlement voucher, rate confirmation and POD are already in the document model, alongside the checksum that proves a file was not swapped mid-dispute. Uploading one is not built yet. Planned
The math that runs
Illustration — sample dates, real arithmetic. The two money figures are what the platform computes today, at the constant the domain module falls back to when no rate is on file; the two marked Planned are what it cannot do yet.
Knowing the number is not the same as billing it.
Every drayage carrier already knows this in reverse: the per diem you eat is visible weeks before anyone decides who pays for it. DrayBase closes the first half of that gap today and none of the second half. Saying so is cheaper than being found out on an implementation call.
The financial loopNone of it built
Six pieces, and a switch on none of them
This is the roadmap, not the changelog. Operations first, then drayage depth, then the money — closing the financial loop before the moves underneath it are solid produces invoices nobody trusts, which is worse than no invoices at all.
Accounting sync, EDI 210 and factoring sit further out than this list, and there is no connector written for any of them — not QuickBooks, not Sage, not NetSuite. The pricing agent that reads your own rate history depends on a tariff engine existing first, so it queues behind row 01. Order of work is on the roadmap.
How it gets built
Three rules the billing module has to obey
An accessorial with no arrival time, no gate timestamp and no document behind it is a charge you lose on the phone. If the evidence is not on the record, the charge does not get generated — it gets flagged for a human.
The customer record already stores whether that account pays without a POD attached. The invoice run will honour that flag instead of asking someone in billing to remember which of forty customers is strict about it.
Money is integer cents everywhere in the schema already. The charge ledger will be modeled the way the load history is — append-only, so a corrected invoice leaves a correction rather than overwriting what was sent.
QuestionsStraight answers
What a controller asks first
Can DrayBase invoice my customers today?
No. There is no invoice table, no charge table and no billing endpoint in the API. What exists today is a read-only dispatch board, a platform status feed and the two public forms on this website. If anyone tells you otherwise on a call, ask them to share their screen.
Does it sync with QuickBooks?
Not yet, and there is no connector started. An accounting sync is only worth building once charges and invoices exist to sync, and the interesting half of that work is not the export — it is repairing a sync that failed at 2am without duplicating an invoice your customer already received.
What about detention, per diem and demurrage billing?
This is the part closest to real. The clocks, the negotiated daily rates and the money at risk are computed per container today, and that exposure is rolled up across the operation, with the source and the freshness of the underlying terminal data carried alongside every date. What is missing is the step that turns an exposure figure into a billable line with a rule about who owes it. See free-time tracking for the half that works.
Do you handle owner-operator settlements?
Planned. The pieces a settlement needs are modeled: driver type as company, owner-operator or fleet-owner driver, a pay percentage on the fleet owner, and pay recorded per leg rather than per load. The weekly run that turns those into a voucher with deductions and escrow is not written. Drivers and settlements data covers what is on the record.
Will there be a tariff you can test before it goes live?
That is the intent — a place to run a real lane through a rate set and see which rule won, before the rule starts pricing loads. Tariff precedence is where drayage billing engines usually go wrong: not the arithmetic, but explaining why this accessorial applied and that effective date did not. It is not built.
When does billing land?
We are not going to give you a quarter. The financial loop comes after the operating surface and the drayage depth underneath it, because a billing module built on moves nobody has run in anger produces invoices nobody signs. What we will do is publish it here the day it changes.
Early access
Bring us your ugliest accessorial
The tariff engine gets designed against real rate sheets, not against a spec. If you run NY / NJ lanes and you have a customer whose accessorial rules nobody in your office can explain from memory, that is exactly the case we want in front of us before a line of it is written.
More of the platform: the whole surface · dispatcher board · containers and free time · chassis · street turns · drivers · agents · pricing