Skip to main content

Transactions and insights at Kitt

One ledger read at two altitudes. Clean books for accountants at booking time, and a picture of compliance CFOs could act on.

Context

Kitt was a corporate travel platform for companies in the GCC. Booking a trip was never the hard part. The mess started after it, and ran until the books closed a month later.

Problem

The accountant reconciles backwards. The agency invoice lands weeks late, bundles several trips into one line, and drifts from the card statement it is meant to match. Every tool we looked at treated this as an export problem. It is a timing problem.

The CFO has the opposite one. There is a policy, and whether anyone follows it is a feeling rather than a number.

Scope

The obvious build is two products, each with its own pipeline and its own version of the truth. We refused, and that refusal is the whole case study.

One set of records, read at two altitudes. The accountant reads rows, the CFO reads totals, and the totals are just the rows grouped. A number nobody can drill into is a number nobody trusts.

One ledger, two altitudesA confirmed booking becomes a single transaction record, coded at booking rather than reconstructed at month end. That same record set is read two ways: accountants work at row level, CFOs work at pattern level. Every grouped number drills back down to the rows that produced it, until it lands on one booking and its receipt.Booking confirmedpolicy checked, approval loggedOne transaction recordcoded at booking, not reconstructed at month endAccountantreads one row at a timeCFOreads it groupedevery grouped number opens its rowsdown to one booking and its receipt

Solution

A confirmed booking becomes a finished accounting record on the spot: traveller, cost centre, tax code, the card that paid, the statement reference, the receipt. All of it attached the moment the booking confirms.

So nobody codes it afterwards, because there is nothing left to code. The trip arrives already carrying everything finance is going to ask it.

A table accountants trust

The real competitor here is Excel, and Excel's advantage is that it never surprises you. So the ledger gives up every trick a modern table wants to do. Column order is fixed and nothing collapses or reorders itself. Nothing lives only in a hover, because a value you have to go looking for is a value you cannot check. Every row is complete on its own line. And the CSV export carries exactly the columns on screen in exactly that order, so leaving for a spreadsheet is not an escape hatch from a table that failed you.

The same records, as totals

The CFO's view is the identical dataset grouped: spend by type, by cost centre, by month. Hovering a month breaks it back down into the cost centres that made it, and from there into the bookings. Nothing here is calculated anywhere else, which is why the two views can never disagree.

Compliance without policing

This was a tone problem before it was an interface problem. A CFO needs proof the policy is working, and a traveller needs to not feel watched, and the same screen has to do both.

Two rules got it there. Lead with a gap rather than a verdict: the headline is actual spend against what the trip could have cost, and the difference is called excess, not a violation. And name the rule rather than the person, so breaches are reported by which policy was crossed and by how much, with people and departments as a second-order breakdown rather than the headline.

Leakage

The number nobody was tracking, because it does not look like waste. Money lost to friction rather than to decisions: cancellation penalties, modification penalties, the cost of booking three days out instead of three weeks. All of it sits inside spend that reads as legitimate, which is exactly why it survives a budget review.

So it gets its own panel, split by cause, and every penalty in it opens onto the booking and the person it came from. It was the number customers reacted to hardest, because it was the first time anyone had put a figure on it.