Skyhawk Operations Platform
A proposal for unifying inventory, finance, and project planning across the Skyhawk catering operation, built around how the business actually runs, not how accounting software thinks it should.
A central-kitchen catering operation running on manual reconciliation.
Skyhawk processes 5–10 purchase invoices per day, books them in weekly or bi-weekly batches, and reconstructs project costing in spreadsheets after the fact.
POs are sent as plain-text emails. Suppliers upload invoices manually. Inventory is tracked mentally between start- and end-of-month counts.
The system proposed here replaces that with an integrated platform where every transaction simultaneously updates a financial ledger and an inventory ledger, all rolled up to the project.
What breaks today.
No mid-month inventory visibility
The team knows opening and closing stock but nothing in between. Over- and under-ordering follow.
Costs not tied to projects
Ingredients, labor, and petty cash float free of the project that consumed them. True margin is invisible.
Wastage tracking is unreliable
Especially for cooked dishes with many ingredients, variance disappears into mental tracking.
Proposal budgets live in Excel
Ruby's planning sheets run on assumptions, disconnected from actual inventory items and live project data.
Three documents, one truth.
Every supplier order generates three documents: the purchase order (intention to buy), the purchase invoice (actual purchase), and the delivery note (proof of receipt). The system reconciles all three, flags mismatches, and updates the inventory ledger and financial ledger in lockstep.
Issue PO
Business sends a purchase order for required items. PO is logged against the project driving demand.
Receive Invoice
Supplier invoice captured automatically. Line items, totals, and tax extracted by the AI layer.
Verify Delivery
Delivery note matched against PO. Mismatches (ordered 4, received 3) flagged for accept, partial-receive, or reject.
Post Entries
Inventory ledger updates quantities. Financial ledger posts cost. Both sides stay in sync; no cost without a corresponding item movement.
Every cost has an item. Every item has a cost.
The financial ledger captures debits, credits, and chart-of-accounts mapping for every transaction, and stays continuously synchronized with the inventory ledger. A cost never appears without a corresponding item movement, and vice versa.
Cost Posting
Purchase invoices, petty cash, and labor allocations post directly to the ledger. Each entry inherits its project tag and category.
Revenue Issuance
Customer invoices issue directly from the project. No COGS or ingredient exposure to the client, line items only.
Recurring Contracts
Bi-weekly and other recurring billing cycles auto-generate on schedule. Yearly contracts run without manual intervention.
Reconciliation
Uploaded bank statements match transfers against outstanding invoices and petty cash. Project closes when payment lands.
The project is the unit of truth.
Every job runs as a Project. All costs, revenue, labor, and inventory attach to it. The system tracks each project through a customizable status pipeline, at every transition, financial and operational state move together.
Planning
Inventory allocated, costs estimated, team tagged.
Preparation
Kitchen executes; transfers in/out logged against allocation.
Pending
Under final review before dispatch and invoicing.
Approved
Invoice issued, project delivered, awaiting payment.
Closed
Paid, reconciled, variance logged, project locked.
From inbox to ledger, without retyping.
A dedicated mailbox (e.g. finance@skyhawk.com) auto-absorbs invoices, POs, and delivery notes, whether forwarded by suppliers, uploaded directly, or photographed and sent via WhatsApp. The AI layer scans each document, extracts structured data, and stages it for review.
Ingest
Documents arrive by email, upload, or WhatsApp. Each lands in a central Documents queue tagged by source.
Extract
AI reads the document, pulls line items, totals, supplier, VAT, and dates. Confidence scores flag anything unclear.
Stage
Extracted entries appear in a review pane. Operator confirms or corrects; system learns from each correction over time.
Post
On confirmation, ledger transaction and inventory entry are created in one step. No double entry, no copy-paste.
People are a line item too.
Labor cost is allocated to projects by tracking employee hours. Infaaz spends 3 hours on Project A and 5 hours on Project B at his hourly rate. Some projects allocate hours ahead; others are reconciled after the fact.
Internal rates · external flexibility
- Internal employees carry fixed hourly rates derived from salary.
- External hires added per engagement with adjustable rates.
- Hours planned upfront or entered post-facto at project close.
Salaries stay hidden from time-loggers
WhatsApp a receipt. Done.
Petty cash purchases (a last-minute pre-made dessert, supermarket whipped cream, a Metro run) currently bypass the inventory and ledger system entirely. WhatsApp receipt capture closes that gap and routes each spend to the project that drove it.
Capture
Team member photographs the receipt and sends it to the Skyhawk WhatsApp number. Photo and metadata land in the Documents queue.
Classify
AI identifies supplier, category (food, transport, non-food, rental), and amount. Operator confirms project allocation.
Post
Ledger entry created against petty cash. If the receipt represents an inventory item, inventory ledger updates too.
Allocate
Cost flows into the project's P&L, even informal cash purchases show up in true project margin.
Plan in assumptions. Execute in items.
Ruby builds proposal budgets in Excel before the project exists in any real form, 12 people at AED 100, AED 900 food cost estimate. The platform preserves this assumption-based planning, then keeps it side-by-side with actuals once the project runs.
Budget templates
- Templated line items: food, labor, rental, transport
- Tagged team members fill in their sections
- Email auto-notifies assignees with deadlines
- Output: a complete proposal P&L for client review
Live project
- Created once the engagement is confirmed
- Linked to real inventory items, not assumptions
- Planned and actual displayed side-by-side
- Variance flagged automatically at close
Two levels of wastage. One activity log.
Wastage operates at two distinct levels: independent of any project, and within a specific project's lifecycle. The system tracks both, and an activity log captures every state change so variance never disappears into mental tracking.
Item-level
Wastage that happens to inventory regardless of any project, e.g. milk expires in the central kitchen and is written off directly against the inventory ledger.
Project-level
5 units allocated, 3 used, the rest returned, expired, or written off at close. Variance is logged against the project that consumed it.
Activity log
Every change captured: items moved, reassigned as waste, locked at close. A Kanban-style view surfaces drift between allocation and actual.
Most payments arrive in pieces.
Customer payments rarely arrive as a single transfer, the standard pattern is 50% upfront and 50% on or after delivery, sometimes split into more installments. The system tracks each payment schedule explicitly and only closes a project when the full balance lands.
Schedule
Each invoice carries its payment schedule: 1 of 2, 2 of 2, or whatever installment cadence the client uses. Fully customizable.
Match
Uploaded bank statements are matched against outstanding invoices. The system pairs transfers to projects; operator confirms on ambiguity.
Track
Project status reflects payment progress: Approved = awaiting payment, Closed = fully reconciled. Partial payments hold projects in Approved.
Close
Once the final installment lands, project locks. Ledger, inventory, labor, and variance are sealed, the project becomes an immutable record.
Configurable guardrails, not generic ones.
Approval rules, permission levels, and notification triggers are configurable per category, so the system bends around how Skyhawk already works, rather than forcing the team into a generic finance-software workflow.
Per-category rules
Some expense types auto-approve; others route to a designated reviewer who attaches the invoice and verifies pricing. Posting blocked until sign-off.
Three levels, customizable
Admin · full access. User · scoped edits. Guest · read-only. Salary visibility is gated separately from time-logging access.
Email & WhatsApp
Payment due reminders, project status transitions, approval requests. Each user toggles which channels they receive.
Ahead of the timeline, by design.
UAE e-invoicing rolls out in phases. Skyhawk is well below the mandatory threshold for the near term, but the platform is being built e-invoicing-ready so adoption is a switch, not a project. Equivalent regimes already live in the UK, Saudi Arabia, and Pakistan, the architecture follows a known pattern.
Voluntary pilot
Pilot phase opens. Businesses can opt in to test integration with the tax authority.
Mandatory · 50M+
Businesses above AED 50M revenue must adopt. Skyhawk remains below this threshold.
Full adoption
All businesses must adopt. Skyhawk's e-invoicing infrastructure is already in place.
80/20 documentation, direct iteration, pre-season go-live.
Crossval will document three workflow specifications (Inventory, Finance, Planning), each structured around the 80% standard flow with a dedicated section for the 20% edge cases. The differentiator from off-the-shelf platforms is direct access to decision-makers: client feedback translates into system changes in days, not release cycles.
Document the 80%
Three specs: Inventory, Finance, Planning. Standard flow first, edge cases sectioned separately.
Build & iterate
Direct line to Crossval decision-makers. Changes ship in days, not quarters. Your fingerprints in the blueprint.
Onboard pre-season
Go-live targeted before catering season opens, no learning curve during peak operations.
Slack · 4h SLA
Dedicated support channel with a 4-hour response SLA. Direct access, not a ticketing queue.
Four things to unlock go-live.
These run in parallel. None blocks the others. The goal: enter the catering season with the system already absorbed into daily routine, not learning it in production.