How to configure an Advanced-mode MDF program, and the full lifecycle a plan and its claims move through — from submission to an approved payout. Screens shown from both the admin console and the participant-facing website.
On this page
Overview
Marketing Development Funds (MDF) let a brand fund a partner or dealer's marketing activity, then review and pay out what they actually spent. Every program runs in one of two modes:
- Simple — one flat requested budget per plan, one flat amount per claim. The original, still-default behaviour.
- Advanced — a plan is funded per expense category (e.g. "Digital content" at 40%, capped $2,000; "Trade shows" at 50%, capped $1,000), and a claim is a set of itemized line items, each costed against its category's agreed rate and cap. This guide covers Advanced mode.
Two people carry this process: an admin (or a staff member with the marketAdmin role) who configures programs and reviews submissions, and a participant — a dealer or partner with the mdfParticipant role — who submits plans and claims for their own spend, self-service, from the website.
Configure a program
Admin console · one-time account setup, then per-program
once per account Define expense categories & items
Advanced-mode expense items are shared across every program in the account, so they're configured once, in Marketing Development Funds → Settings. Set an Expense Category — a product category name such as "MDF Expenses" — then add the individual Expense Items a claim line can be costed against, e.g. Digital content, Trade shows.
per program Set the program's mode and payout series
On a program's Modify Configuration panel, switch Claim Mode from Simple to Advanced. Two more fields matter here:
- Total Program Budget — an optional overall fund pool, purely for showing committed-vs-remaining spend on the program list. Leave it blank if the program has no fixed pool.
- Payout Data Series — the sales-data series that approved claim line items are copied into on approval. Use Create a new data series to have Kademi pre-wire the custom fields and Points Allocation Source a payout rule expects, rather than configuring seven fields by hand in KSalesData.
Modify ConfigurationMode, budget pool, and the payout data series
Once plans and claims start moving, the program's own overview shows committed spend against that pool at a glance:
Roles & access
Who can do what, and where it's granted
MDF defines two roles. Neither is granted automatically — both are assigned deliberately, the same way WarrantyUser works for KWarranty:
| Role | Who | Grants | Where to assign it |
|---|---|---|---|
marketAdmin |
Staff who need MDF access but not a full Administrator login | Manage programs, review and approve/reject plans & claims, run reports | Admin → Manage Users → a staff profile's roles |
mdfParticipant |
Dealers / partners submitting their own spend | Submit and view their own plans and claims from the website — nothing else | Admin → Manage Groups → the participant group's Roles panel |
GRANT SCOPE
Group-level grants normally use Their own organisation as the role's scope — the role then follows each member wherever they belong, rather than being pinned to one fixed org. Grant it to whichever group represents your eligible participants (often the account's base "Participants" group, or a narrower dealer/partner group).
Every self-service action a participant takes — viewing a plan, saving a claim's line items, uploading an invoice — independently re-checks that the record actually belongs to them, on top of this coarse role grant. A participant can never edit another participant's plan or claim, or touch one that isn't in draft.
Submit & approve a plan
Participant submits → admin sets the funding rates → approved
Draft / Pending → Approved
Draft / Pending → Rejected → resubmitted as Pending
participant Submit a plan
On the program's promotion page, a participant fills in a description of the planned activity, optionally requests a budget (if the program allows it), and attaches any supporting files — the same minimal form used for Simple-mode plans. Advanced-mode expense rates aren't set here; they're the brand's decision, made at review.
admin Set the plan's funding contributions
Reviewing a pending plan, the admin uses + Add expense item to attach one or more of the account's expense items to this specific plan, each with its own Percentage funding rate and dollar Cap. The plan's Total Budget is simply the sum of those caps.
Plan detail, pendingFunding Contributions editor — rate and cap per expense item
From here the admin either Approves the plan, or Rejects it with a required reason:
Reject dialog - A reason is required and shown back to the participant
A rejected plan shows the reason directly on its detail page, and can be reset to Pending for further changes:
Plan detail, rejected - Reason is visible to the admin — and to the participant on the website
Once approved, the plan is locked: contributions can no longer change, and it becomes claimable. The admin's approved view shows the agreed rates alongside how much of each cap has actually been claimed:
Plan detail, approved - Locked contributions and live budget-utilization stats
The participant sees the identical agreed contributions on their own plan page on the website, alongside a running list of the claims they've made against it:
Submit a claim
Participant creates a minimal claim, then builds it out on its own detail page
participant Start a claim
From the approved plan's Make a Claim tab, the participant optionally attaches an invoice and submits. This creates a minimal draft claim — no line items yet — and takes them straight to the claim's own detail page to build it out.
participant Add invoices and line items
On the claim's detail page, while it's still in draft, the participant can:
- Attach further invoices or proof of purchase, and remove any before submitting.
- Scan with AI — sends an invoice to an LLM vision model, which proposes line items (description, quantity, amount) and flags any that look like duplicates of ones already on the claim. This is always a suggestion; nothing is added until the participant reviews and confirms it.
- Add or edit line items directly — each one linked to an expense item from the plan's agreed contributions.
The payout for each line calculates live as it's edited — amount × the plan's agreed rate for that expense type, capped by whatever's left of that item's ceiling:
Claim detail, draft - Editing a line item — description, quantity, amount, expense type
Saving line items is what leaves the claim ready for review — there's no separate "submit" step once the description and line items are in place.
Review & payout
Admin approves → a payout record is created → points follow
admin Review the claim
The admin's claim view mirrors the participant's line-item and invoice panels exactly, plus the totals that matter for a decision: total claimed, computed payout, and what the plan's remaining budget will be after this payout, if approved.
admin Approve and what happens next
Approving locks the claim and, for every line item linked to an expense item, writes a permanent record to the program's payout data series: the amount, the percentage and cap as they stood at approval, the expense item, and the originating plan and claim. That snapshot survives even if the plan's agreed rates are changed later — it's the durable record of what was actually in effect if a payout is ever challenged.
Claim review, approved - Payout data record created for the points pipeline
mdf-payouts data series - One row per approved line item, carrying the plan/claim/rate/cap that produced it
From there, the account's configured Points Allocation Source reads those records on its own processing cycle and converts them into points — this is where "points" are functioning as money, not a loyalty currency. Once points land, Kademi's normal disbursement mechanics take over unchanged: card funding, Xe.com/Blackhawk electronic payment, or whatever the account has configured, eventually turning the points into a real payment to the participant.
The participant sees their own claim reach the same end state, with a reference to the payout that was created:
Reference
Status values and where each thing lives
Plan & claim status
| Status | Plan | Claim |
|---|---|---|
| Pending | Editable — contributions, budget and details can still change | Draft — line items and invoices can still change |
| Approved | Locked; claims can now be made against it | Locked; a payout data record has been created |
| Rejected | Reason shown to the participant; resettable to Pending | Reason shown to the participant |
Where things are configured
| Setting | Location | Scope |
|---|---|---|
| Expense category & items | Marketing Development Funds → Settings | Whole account |
| Program mode, budget, payout series | Program → Modify Configuration | Per program |
| Funding rate & cap per expense item | Plan detail → Funding Contributions | Per plan, set at review |
| Points conversion rule | The program's Payout Data Series → Points Allocation Source | Per program |
marketAdmin role |
Manage Users → a staff profile | Per staff member |
mdfParticipant role |
Manage Groups → a group's Roles panel | Per group, "their own organisation" |