01 / About Tinkerbird
Practical AI for
everyday work
We help businesses put AI to work on the jobs that take up too much time, from capturing paper records to checking invoices and following up on meetings.
Tinkerbird is Akoma’s AI and digital practice. We start with the way your team works and test practical tools on your own records, before taking on a wider build.
We use these tools in our own business too, for research, project records, meeting follow-up and producing websites and proposals. That practical experience is what we bring to Devland.
Explore the Devland proposalClient work and exploration
AI across different businesses
Bakery
We’re trialling daily reports and next-day bake planning from production and stock records, with missing or conflicting figures flagged for review.
Transport company
We’re developing an invoicing proposal to reduce manual preparation and reconciliation, starting with a sample of completed work.
Family-run safari camp
We’ve built website previews bringing accommodation, activities and enquiry routes together for the family to review.
Foreign-exchange business
We’re exploring sales research, prospect management and automation around the business’s chosen customer relationship management system.
Devland / Purchase to payment
Supplier deals and recons
The deals your buyers agree with supplier reps live in the order book and in people’s heads, not in React. Invoices arrive on paper and are typed in line by line, and Muhammed checks every recon pack himself. Claims get missed.
- 60 to 65suppliers cited; buyer and group coverage to confirm
- 15 minutesroughly, for Muhammed to check an ordinary recon pack
- 7 to 10 daysfor a Clover pack, with several deals running
- Decemberspent going through suppliers one by one to plan the year
Figures as you gave them on 26 October. Tally claims rarely appear on the invoice and have to be raised separately, and last year’s Kellogg’s birthday claim is only being signed now. As you put it, “If we don’t pick up those errors, we’re losing money.”
02 / Purchase to payment
Target workflow, subject to React integration
- 01
Deal
Buyers and supplier reps
Today
- Terms agreed with the rep in person
- Special terms written in the order book
- Deal sheet scanned and filed, never loaded into React
Proposed
The final negotiated order and special terms become a structured deal record. The buyer approves it before any supported React posting.
- 02
Receiving
Gate and store staff
Today
- Goods counted against the invoice
- Invoice stamped as received
- Paperwork stapled into a batch and carried to admin
Proposed
Count and stamp as today, then scan or photograph the invoice and any return note.
- 03
Capture
Admin office
Today
- Invoice typed into React line by line
- Returns typed in
- Store paperwork captured again at head office
Proposed
The stamped scan supplies invoice and return data for review and supported React posting. Unclear lines and duplicates wait for a person.
- 04
Claims
Admin office
Today
- Prices checked against the order book
- Tally claims raised separately
- Golf day, birthday and billboard money tracked by hand
Proposed
Price, tally and allowance claims are drafted from the deal and the invoice, including allowances such as R50,000 a truckload.
- 05
Recon
Admin and Muhammed
Today
- Recon pack built by hand at month end
- Muhammed checks every document and deal sheet
- Muhammed approves the payment
Proposed
A batch follows each supplier’s weekly, fortnightly or monthly cycle. Admin checks completeness; Muhammed reviews exceptions and approves.
- 06
Payment and reporting
Accounts and buyers
Today
- Invoices ticked off and payments split into requisitions
- Each supplier’s year pieced together in December
Proposed
Payments carry on as today. A monthly report per supplier builds the year’s tallies, discounts and ad hoc money, and shows any claim not collected.
React may already cover much of this work. The priority is getting complete, approved information into it at the right time. After reviewing the pack, we check your installed modules and supported integration route before designing a live pilot. No posting interface has yet been verified.
Approvals: the physical count, every approval and all supplier conversations stay with your team. Nothing is paid or sent to a supplier by us. Supplier meetings are recorded only with the supplier’s agreement.
03 / First step
Recon pack rebuild
We propose testing one supplier’s complete, closed period, from the negotiated order to the payment approval pack. We rebuild it from the source records and compare every result with your completed recon. This is the first test of the wider capture-to-recon workflow.
Inputs
The final negotiated order and special terms, stamped invoices, returns, credit notes, existing claims, supplier statement, completed recon and payment approval document. Include store-originating paperwork where it forms part of that pack.
Aadil or his nominee walks us through capture and recon preparation; the buyer explains the deal rules. We record how missing paperwork, disputed prices and store charges are handled.
Outputs
You receive a document register, extracted invoice data, an approved-terms worksheet, draft claims and a rebuilt recon. Each difference links back to its source. A supplier trading report sample separates agreed allowances, claims raised and credits received.
We also return an exception list and a proposed live-pilot scope, with the capture steps, React dependencies and baseline time measurements. We do not count a drafted claim as money recovered.
Time: we confirm this once we’ve looked through the pack.
Fee: to be agreed before work starts, including VAT. No commitment to a later build or ongoing service.
One pack tests extraction, deal rules and reconciliation. It does not prove live automation, all suppliers or a saving. Any wider pilot needs its own approval.
Starting point
The problem starts before the recon: deal terms are not loaded, and stamped invoices are typed in manually. A complete pack lets us test that chain on known records before changing receiving or connecting to React. The next stage must test capture through to approval, not just another price checker.
04 / Roadmap
Purchase to payment and finance
Your aim is to digitise in stages, towards a live view across the business. After the first step, each stage has its own scope, price and approval. We price the later stages once we’ve seen the pack and your React setup.
- 01
Deals on record
Record the final negotiated terms, validity dates, product and pack sizes, tallies, rebate conditions and ad hoc contributions. Buyer approval comes before posting.
- 02
Scanning at receiving
After the count, the invoice and return notes are scanned and captured. Stores follow once it works at head office.
- 03
Claims and recon batches
Draft claims against approved terms, match supplier statements and flag missing invoices, credit notes or proof of delivery. Produce batches on each supplier’s agreed cycle.
- 04
Supplier trading report
A monthly report per supplier that builds the year: tallies, discounts and ad hoc money such as golf days and birthdays, with missing claims flagged. It replaces December’s manual review.
- 05
Finance
Creditors, then debtors, once the purchase records are reliable. This builds towards the live view of the business you asked for.
05 / Next step
Pack review session
Zubair coordinates one pack-review session with Muhammed and Aadil or his nominee. We use it to confirm the source documents and agree the first-step fee, delivery date and acceptance checks before work starts.
Session date to be agreed. React questions follow the pack review; no vendor contact is needed beforehand.
Other requests
Meeting minutes. We turn recordings into short minutes with clear actions. View the sample from 22 October.
Export invoices. Invoices could be made from the proformas that arrive by email, if React accepts an import.
Export invoicing is outside the first scope. Marketing is handled separately and is not part of this proposal.
Supporting detail
Rebuild review and limits
Every document in the pack ends as a supported match or a named exception. Amounts, dates, references, prices, tallies, allowances and rebates agree with the source, or the difference is explained. Unclear scans and missing deal terms stay open rather than guessed. Aadil, or his nominee, checks our version against the team’s finished pack, and no saving is claimed before it is measured.
Rebates that depend on volumes or dates stay flagged until the condition is evidenced. Partial payments, credit notes, VAT, pack sizes and price dates follow the rules your team gives us.
The first step includes no payments, React entries, supplier messages or claims sent on your behalf, and no change at receiving. It works from the scanned pack and needs no React login.
Acceptance checks and pilot gate
Every supplied document must appear once in the register or be identified as a duplicate. Extracted quantities, prices, VAT, totals and references must match the source or remain flagged. Each claim must cite an approved term and show its calculation; no claim is raised twice. The recon must explain every difference from the completed pack, including missing credits and statement items.
Before a live pilot, agree numeric accuracy and processing-time targets from the sample, confirm a supported React read/write route and test duplicate prevention, failed postings and approval controls. A later pilot covers one agreed supplier and receiving location. Store expansion and wider finance follow only after review. Payment execution, supplier messages and automatic claim submission are excluded.
Data handling
We agree in writing the shared folder, who can see it, which tools process it and how long we keep it. Send only what the pack needs. No live-system passwords are required. Any recording of a supplier meeting needs that supplier’s agreement.
Proposal basis
Prepared from our meetings on 22 and 26 October, the registered follow-up transcript and Mo’s notes; refined following Zubair’s 27 October request. React, Excel exports and Aadil’s role as head of accounts are confirmed. Figures are as you gave them; who gives final sign-off is still to be confirmed. No Devland volume, saving or implementation commitment is assumed.