Transactions and insights at Kitt
One ledger read at two altitudes. The design work behind giving accountants clean books at booking time and CFOs a picture of compliance they could act on.
- Role
- Co-founder and CPO. Product and design
- Company
- Kitt, B2B corporate travel for GCC enterprise clients
- Contributors
- Imad, Prajna, Kunal - Founding team
- Try it
- A live walkthrough of the product sits at demo.kitthq.com
Booking a trip was never the hard part. The mess started the day after the booking and ran until the books closed a month later.
Here is what that month looked like for the finance team of a 60-person company.
Accountant
Reconciling backwards
The agency invoice lands two to four weeks after travel, bundling three trips into one line. Amounts, dates and merchant names all drift from the card statement. You hold a charge for AED 3,450 and go hunting for the trip it belongs to.
CFO
A policy nobody could measure
The travel policy is written and circulated. Whether anyone follows it is a feeling, not a number, and the only evidence arrives long after any decision could be made about it.
Every booking lands with its accounting already filled in
The shape of it
A confirmed booking does not become a line on an invoice for finance to interpret later. It becomes a finished accounting record straight away.
That record carries everything the books need, captured at booking rather than reconstructed at month end.
Everything downstream reads that same set of records. The accountant reads it one row at a time. The CFO reads it grouped.
One set of records, read as rows or as totals
Two people, one dataset
The first real design decision was refusing to build two products.
An accountant and a CFO want opposite things from the same data.
The accountant works at row level: this booking, this traveller, this cost centre, this VAT code, this receipt. Anything summarised is anything they cannot verify, and a number they cannot drill into is a number they will not sign off.
The CFO works at pattern level. They do not care that Ahmed flew to Riyadh on the ninth. They care that 45% of sales bookings happen inside seven days of travel, because that is a behaviour they can go and change.
The tempting answer is a detailed table for one and a dashboard for the other, built separately. We had seen where that goes: two surfaces drift, the totals stop agreeing, and finance loses trust in both.
The same records as the ledger, read as totals and trends
Making a table that accountants trust
Accountants live in Excel. That is the actual competitor, not another travel product, and it sets a bar most web tables fail to clear.
What we learned watching people work is that trust in a table is mostly about the absence of surprises. Excel never reflows on you. It never hides a column at a narrower window. It never paginates you away from the row you were looking at.
- 01
Fixed column order, always
Nothing reorders, nothing collapses at a narrower window. A person should be able to point at a position on screen and be right about it tomorrow.
- 02
Nothing lives in a hover state
A hover state does not exist when you print the screen and hand it to a colleague, which is what people actually do with this table.
- 03
Every row is complete on its own
"Emirates, AED 3,450" is the problem restated, not solved. Traveller, cost centre, payment method, tax code, reference and receipt all sit on the line.
- 04
Export is a feature, not an escape hatch
Accountants were going to move this into their own system regardless. The CSV columns match the table on screen, so nobody reconciles the export against the thing it came from.
Fitting that much onto a scannable line was the actual craft work. Amounts use fixed-width numerics so they align on the decimal. The traveller appears as a name rather than an ID. The booking reference is set in monospace, because its entire job is to be compared against a card statement character by character.
Sorting the ledger, and a tooltip explaining why a row is flagged
Attribution belongs at booking
The single biggest change was moving where categorisation happens.
Traditional flows put coding at the end. Spend happens, then somebody decides which department and project it belonged to, weeks after the context has evaporated. Every error in the books traces back to that gap.
Kitt moves the decision to setup. Finance defines cost centres once and links travellers to them, so a confirmed booking already knows which cost centre it hits, which card paid for it, and who travelled.
| Agency invoice | Kitt record | |
|---|---|---|
| Arrives | Two to four weeks after travel | The moment the booking confirms |
| Matches the statement | Rarely, amounts and dates drift | Exactly, on a shared reference |
| Direction of work | Backwards, from a charge to a trip | Forwards, from a booking to a charge |
| Who codes it | Finance, weeks later, from memory | Nobody, it was coded at booking |
| Audit trail | Email threads | Attached to the row |
One trip, carrying everything finance will ask for
Compliance, and how much to police
The hardest section to get right, and a tone problem before it is an interface problem.
A CFO needs to know whether the policy is working. A traveller needs to not feel watched. Travel is already a chore people resent, and a screen that reads as surveillance pushes them back to booking on their own card, which destroys the data quality the whole system depends on.
Two decisions came out of holding both of those at once.
- 01
Lead with a gap, not a verdict
The headline is not a count of rules broken. It is actual spend set against optimal spend, with the difference called excess. That frames the question as money left on the table, which is a thing a CFO can go and fix, rather than a list of people who misbehaved.
- 02
Name the rule, not the person
Violations are reported by type and split across flight, hotel and car: star rating rules, booking lead time, price cap. This is the card that actually tells you what to change, because a rule breached forty times is usually a badly written rule.
On the traveller's side of the same policy, the tone stays neutral and arrives earlier. Rules show up while you are choosing rather than after you have booked, and an exception carries its reason with it: the ledger tooltip does not say "violation", it says which limit was passed and by how much.
What was spent against what it could have cost, and what caused the gap
Leakage, the number nobody tracked
Money lost to friction rather than to decisions, hiding inside spend that all looks legitimate.
None of this is fraud, and none of it appears as a line item anyone thinks to look for. Surfacing it meant designing a view around a category of cost the customer did not previously have a word for, so the screen has to teach the concept and report on it at the same time.
What worked was leading with the cause rather than the amount. A number is only interesting once you can see the lever sitting next to it, which is why the total splits into modification and cancellation before it splits into anything else.
This is also where the drill-down rule earns its keep. A penalty total is the kind of figure a CFO immediately wants to argue with, so opening it lands on the individual bookings that produced it, each with its date, its traveller and the department it hit.
Penalties split by cause, and every one can be opened
What we deliberately left out
Two things, both tempting, both declined on purpose.
- 01
No expense reporting module
Everything in Kitt is booked through Kitt, so there is nothing for a traveller to claim back. Adding a reimbursement flow would have re-imported the exact ritual we were removing.
- 02
No ERP integrations before the ledger was right
Clients asked for direct sync early. A two-way integration on top of records we were still refining would have been an expensive way to propagate mistakes. Clean CSV first.