Known beneficiary
Each payable row starts with the beneficiary record approved for the marketplace program.
Marketplaces
Turn approved seller payables into one clear payout run.
Bring the seller, approved amount, currency, and marketplace reference into one batch. Review the rows that need attention and give finance a clean result to reconcile.
Seller referencesItem-level reviewFinance export
Capabilities
Keep the seller payable easy to follow
Marketplace source reference
Use an external reference and metadata to carry the order, booking, or settlement context into the row.
Batch review
Review imported seller rows and identify the items that need attention before processing.
Amount and currency
Keep the approved seller amount and ISO currency explicit on every payout instruction.
Structured result
Export seller IDs, source references, payout states, and provider references for reconciliation.
Exception context
Use item status explanations and reason codes to route the affected seller row for follow-up.
Ops, support, and finance can follow the seller payable from source reference to payout result.
01
Pre-check
Readiness gate
Confirm the beneficiary and program requirements before processing.
02
1 record
Order to seller share
Carry the approved marketplace source reference into the row.
03
Isolate
Held sellers only
Item status and reason details identify the row to review.
04
Export
Finance close
Export structured item outcomes for your accounting process.
How it works
From approved seller share to reviewed result
Your marketplace owns the seller-share calculation. Gruv starts with the approved payable rows and carries them through review, processing, and export.
- 1
Calculate the payable share
Use your marketplace’s order, booking, refund, fee, and reserve rules to approve the amount owed to each seller.
- 2
Create the seller rows
Carry the seller, amount, currency, order or booking reference, memo, and relevant program metadata into the payout batch.
- 3
Review exceptions
Use item status, reason codes, and explanations to separate the seller rows that need follow-up from the rest of the run.
- 4
Confirm the release totals
Check beneficiary, amount, and currency before the enabled payout workflow processes the reviewed batch.
- 5
Export the outcome
Return payout states and references to finance, support, and the marketplace systems that own seller communication.
Choose your pattern
Choose the seller-payable pattern you need to support
The source system owns the commercial calculation. The payout batch begins with its approved result.
Product marketplace
Carry an approved order settlement into the seller batch
Use this pattern when your commerce system has already accounted for platform fees, returns, reserves, and the amount payable to the seller.
- Retain the order or settlement reference
- Keep the approved seller amount explicit
- Return the payout result to reconciliation
Services marketplace
Pay service providers from approved booking totals
Use this pattern after your booking system has applied session status, cancellations, fees, and the provider share.
- Carry the booking or cycle reference
- Review the provider row before processing
- Export item status for support and finance
B2B procurement
Carry an approved supplier milestone into a payout run
Use this pattern when the procurement system has approved the supplier, milestone, payable amount, and due date.
- Keep the PO or milestone reference
- Preserve amount and currency per supplier
- Match the result back to the approved payable
Rental marketplace
Pay hosts from a finalized stay settlement
Use this pattern after the rental platform has finalized the stay, fees, adjustments, reserve treatment, and host amount.
- Carry the stay or settlement reference
- Separate rows that need review
- Give support a traceable payout result
Four decisions that make seller payouts easier to explain
Where is the seller share calculated?
Keep allocation, platform fees, refunds, reserves, and adjustments in the marketplace system that owns those commercial rules.
What stops a seller from entering the run?
Define the beneficiary, payout method, program checks, and review owner before the payable file reaches processing.
How do disputes change the amount?
Decide whether a dispute changes the source payable before import or creates a later adjustment tied to the original reference.
Which team explains the result?
Agree on the statuses, reason details, and references that support needs before it answers a seller payout question.
Frequently Asked Questions
Does Gruv calculate each seller share?+
Your marketplace should remain the source of truth for order, booking, fee, refund, reserve, and seller-share rules. Gruv starts from the approved payable amount and carries its references through the payout batch.
Can we start with a seller-payable CSV?+
The current batch workflow accepts CSV text or structured items. Each row needs a beneficiary, amount, and currency; external references, memos, and metadata can carry marketplace context.
What can support use to investigate a seller payout?+
Start with the batch item, seller or beneficiary reference, external source reference, payout state, reason codes, status explanation, and provider reference when one is available.
How does finance reconcile payouts against marketplace activity?+
Export the batch items and match each seller, amount, currency, source reference, payout state, and provider reference to the marketplace settlement record.
What should we confirm before adding another market?+
Confirm the eligible seller types, beneficiary requirements, payout method, currency, provider role, fee and FX treatment, exception owner, and accounting handoff for that market.
Pay your sellers. Close your books.
Start with one approved seller-payable file. Map its references, review path, and finance result before expanding the program.
Bring one seller-payable export and the source references your support team uses today.