Commercial clarity
Pricing should be understandable to finance, sales, customers, and partners. Every charge needs a clear basis, rate source, policy reference, and timing rule.
Overview
YieldForge is more than a quote engine
Most pricing systems stop at calculating a rate. YieldForge is designed to carry pricing logic all the way through funding, accrual, billing, margin analysis, and reporting. That is what allows the same platform to support dynamic pricing, usage-based billing, late fees, multi-source funding, and finance-grade profitability analysis without breaking auditability.
Stateful economics
Actual charges depend on real events: draws, balances, repayments, delinquency, grace periods, waivers, and funding assignments. YieldForge models those directly.
Point-in-time reproducibility
Quotes, billed items, and finance reports must be reproducible later from frozen terms, policy versions, market snapshots, and event history.
The core design principle: separate terms from state from policies. A quote binds terms. Billing follows actual state. Policies determine how both are converted into economics.
Design criteria
What the platform must optimize for
YieldForge should let finance and sales move quickly without losing control. The platform is designed around a few hard criteria that keep pricing fast, extensible, and trustworthy as the business grows.
API-first
All interactions happen through authenticated APIs. Internal tools, customer channels, and partner workflows all call the same backend.
Deterministic
Given the same inputs, timestamps, market snapshots, and policies, the system must produce the same output every time.
Explainable
Every quote, fee, rebate, and allocation must be traceable to rules, data, and effective policy versions.
Extensible
New products should be assembled from shared abstractions like facility, draw, accrual model, and funding model.
Finance-grade
Accruals, billing, margin, partner reporting, close support, and reconciliation must be built in, not bolted on later.
Commercially safe
Support discounts, bundles, and overrides with hard guardrails, approvals, and margin floor enforcement.
Point-in-time aware
Policy effective time, event time, market observation time, and billing time all need explicit treatment.
Auditor-ready
Immutable snapshots, approval history, rerunnable reports, and evidence packs must be available from day one.
Core capabilities
The YieldForge platform stack
The cleanest architecture is a layered platform. Each layer owns one part of the lifecycle so pricing logic stays coherent from initial quote through final margin reporting.
Quote engine
Computes commercial pricing from product inputs, risk, segments, incentives, and dynamic market references. Returns explainable outputs with line items, assumptions, and policy trace.
Terms binding engine
Freezes the exact terms that were offered or accepted, including policy versions, market snapshots, locked spreads, and segment outcomes.
Exposure and accrual engine
Tracks facilities, draws, invoices, installments, balance intervals, delinquency states, and contingent charge behavior. Produces daily or interval-based accrual facts.
Billing engine
Turns accrued amounts and event-based charge policies into statements, billing items, schedules, and settlement outputs. Supports dynamic schedules based on usage.
Funding engine
Selects and allocates one or more funding sources, computes expected and realized cost of capital, and enforces partner and pool constraints.
Margin and allocation engine
Calculates gross margin, retained thresholds, reserve top-ups, partner shares, and campaign funding allocations using auditable waterfalls.
Reporting and controls layer
Supports finance analysis, close, reconciliation, funding partner reporting, auditor evidence, and full drill-down from aggregate metrics to raw economic facts.
Product coverage
Built for a broad credit product portfolio
YieldForge should not hardcode behavior around a single product. It should support multiple credit product families using shared economic primitives and product-specific configurations.
Products covered out of the box
- Recourse and non-recourse factoring
- Spot factoring and portfolio factoring
- Reverse factoring / supply chain finance
- Buy now pay later
- Revolving credit lines
- Term loans
- PO finance
- Future products composed from the same model
Shared abstractions across products
- Facility or product instance
- Draw, obligation, invoice, or installment
- Charge definition and pricing policy
- Accrual and amortization model
- Funding model and source allocation
- Billing cadence and statement rules
- Segment, incentive, and margin logic
- Reporting facts and audit trace
Dynamic pricing
Support live market inputs without sacrificing control
Dynamic pricing should be modeled as formulas over time-bound reference components, not as opaque custom code. YieldForge should be able to blend live reference inputs with internal policy spreads and fees, then explain exactly which market snapshot was used.
Reference-priced components
FX spot, benchmark rates, logistics quotes, insurance costs, or market-driven funding curves can be used as explicit pricing inputs.
Policy-priced components
Risk spreads, operational fees, segment adjustments, bundle discounts, and minimum or maximum charge rules stay under internal control.
State-priced components
Utilization, concentration, liquidity pressure, or urgent turnaround fees can be priced based on current product or funding state.
Quote modes for dynamic products
Indicative
Used for pre-sales or simulation. Can reference live data but is not bookable.
Firm
Bookable for a short TTL. Market snapshot is frozen for the quote validity window.
Locked
Accepted and bound. All locked inputs, spreads, and terms are frozen in a snapshot.
Floating
Contract remains active while one or more components reset on a cadence or event rule.
Examples: FX-linked financing, logistics-cost-linked PO finance, spot factoring priced at draw time, and variable-rate revolving products all fit this model.
Segmentation & incentives
Target pricing by customer, product, performance, and time
YieldForge should support segmentation and incentives as first-class policy objects, including time-based rules like customer tenure, product tenure, rolling volume, clean payment history, and campaign windows.
Segmentation dimensions
- Customer or account
- Partner or channel
- Industry and geography
- Risk tier and underwriting outcome
- Buyer, merchant, or supplier relationship
- Rolling volume or utilization bands
- Behavior signals and delinquency history
- Program membership and contract type
Incentive types
- Immediate discounts or fee waivers
- Volume tiers and rolling rebates
- Bundle pricing across products
- Risk-based pricing and performance bonuses
- Partner-sponsored campaigns
- Retention and loyalty programs
- Negotiated exceptions within guardrails
- Post-period true-ups and clawbacks
Time-based eligibility needs explicit anchors
| Rule type | Possible anchor | Evaluation stage | Why it matters |
|---|---|---|---|
| Customer tenure discount | First funded transaction date | Draw time | New draws may qualify while old ones keep prior economics. |
| Product tenure rebate | Facility activation date | Month-end or quarter-end | Rebate can depend on staying active and performing over time. |
| Rolling volume tier | Trailing 90-day funded volume | Quote or billing cycle close | Allows dynamic pricing or post-period rebate logic. |
| Campaign window | Policy effective dates | Quote or booking time | Ensures the offer only applies during the intended period. |
Important: segment and incentive outcomes must be stamped point-in-time on quotes, draws, accruals, and statements. Historical reporting cannot depend on the customer’s current segment.
Accrual, amortization & billing
Support different economic models without rewriting the engine
Products should not hardcode one repayment or billing pattern. YieldForge should let each charge define its principal basis, accrual method, billing cadence, and accounting recognition model.
Amortization and principal schedule patterns
- Bullet repayment
- Equal principal amortization
- Annuity / level payment
- Interest-only with balloon
- Revolving balance
- Invoice-by-invoice settlement
- Milestone disbursements
- BNPL installment schedules
Accrual and billing patterns
- Simple daily interest
- Compound daily interest
- Discount fee on face value
- Average daily balance billing
- Unused commitment fee
- Minimum period fee true-up
- Upfront origination fee
- Period-end or settlement-based billing
Usage-driven billing works from balance intervals
For products like factoring lines and revolving facilities, a fixed payment schedule is often the wrong abstraction. The system should track balance intervals and accrue financing charges whenever the balance, rate, or delinquency state changes.
Example: factoring line with daily outstanding billing
Day 1 advance 200,000
Day 10 additional advance 100,000
Day 20 repayment 150,000
Rate 12% annualized, ACT/360
Accrual intervals
- Day 1–9: 200,000 outstanding
- Day 10–19: 300,000 outstanding
- Day 20–30: 150,000 outstanding
Cycle financing charge
= 200,000 × 12% × 9/360
+ 300,000 × 12% × 10/360
+ 150,000 × 12% × 11/360
Quoting versus billing: the quote should explain the formula and assumptions. The bill should reflect actual usage, actual balance history, and actual event timing.
Contingent charges
Late fees, overcharges, and grace periods need state machines
Contingent charges such as late fees should be policy-driven and tied to delinquency state, not treated as miscellaneous line items. Grace periods and retroactive late-fee behavior require explicit, auditable lifecycle logic.
Expected charges
Regular financing charges, service fees, commitment fees, and contractual discount fees.
Contingent charges
Late fees, default interest, overlimit fees, return-item fees, extension fees, and recovery-related charges.
Lifecycle states
Eligible, shadow-accrued, posted, billed, waived, reversed, paid, cured, or defaulted.
Grace period example
1
During grace: regular fees continue accruing and late fees accrue only in shadow if the policy says they become payable only when grace is breached.
2
If the customer cures during grace: regular fees remain, shadow late fees are discarded, and nothing late-related is billed.
3
If grace is breached: the system converts shadow late accrual for the grace window into posted late fees and continues posting late fees for subsequent days.
Why this matters: retroactive late fees can be legally and operationally sensitive. The engine should make them explicit, controllable, and explainable on statements and audit traces.
Scope hierarchy
Model product instances and draw instances together
YieldForge should use a hierarchical contract model so facility-level economics and draw-level economics can coexist cleanly. That is essential for products like factoring, reverse factoring, and revolving lines where usage is granular but commercial terms often live at a broader relationship scope.
| Scope | Typical examples | Economics that often live here |
|---|---|---|
| Program | Bank-sponsored facility, channel program, treasury pool | Eligibility constraints, partner economics, reporting obligations |
| Customer agreement | Master terms with a seller or merchant | General pricing framework, discounts, legal terms |
| Facility / product instance | Factoring line between seller and buyer | Line limits, commitment fees, billing cycle, inherited rules |
| Draw / obligation | Specific invoice advance or term-loan disbursement | Locked spread, tenor, due date, invoice-specific fees |
| Installment / delinquency episode | Past-due invoice period, BNPL installment | Late fees, grace rules, collections actions, waivers |
Facility-level policies should provide inherited defaults. Draw-level term snapshots should override what must be locked at the draw, invoice, or installment level. Billing must support both statement-level rollups and drill-down to specific draws.
Funding & capital
Handle multiple funding sources and real cost of capital
Funding should not be an afterthought. YieldForge should model expected funding cost used in pricing and realized funding cost based on actual source allocation, then explain the variance between the two.
What a funding source should define
- Source type, currency, capacity, and tenor constraints
- Cost formula including index, spread, fees, and reserves
- Eligibility rules by product, geography, obligor, or collateral
- Concentration limits and partner-specific covenants
- Reporting obligations and remittance logic
Allocation strategies to support
- Hard assignment to a specific source
- Cheapest eligible source
- Priority waterfall across sources
- Pro rata allocation across a pool
- Constraint-based optimization
Expected versus realized funding cost
Quoted transfer price
The cost basis used to price the customer. Can be a treasury transfer curve, blended expected source mix, or source-specific cost if capital is reserved.
Realized source allocation
The actual funding mix assigned over time. May differ from the quoted assumption due to capacity, eligibility, or rebalancing.
Variance reporting
Finance should be able to see whether margin changed because pricing was wrong, source allocation changed, or cost of capital moved after booking.
Key benefit: this lets sales price against a stable transfer curve while finance still measures realized economics against actual funding assignments.
Finance tooling
A platform the finance team will actually want to use
Finance needs more than exported fees. YieldForge should provide a bottom-up economic operating system with drillable gross margin, close support, funding visibility, and campaign allocation controls.
Margin view
Revenue → Cost → Margin
Drill path
Customer → Facility → Draw
Attribution
Policy + Segment + Funding
Close support
As-of reruns
Core finance workspaces
Margin waterfall explorer
Drill from aggregate gross margin down to billed charges, funding cost, waivers, rebates, loss events, and allocation rules.
Quote vs realized analyzer
Compare expected economics at quote time versus actual economics after usage, delinquency, funding, and collections.
Reconciliation workspace
Track accrued not billed, billed not collected, collected not applied, reversals, waivers, and ties to accounting outputs.
Period close tools
Lock periods, rerun reports as-of close, handle late-arriving data, capture adjustments, and maintain restatement history.
Incentive and rebate workbench
See earned versus paid rebates, campaign budget consumption, accruals, clawbacks, and economics by program.
Funding workbench
Monitor source utilization, weighted cost of funds, eligibility exceptions, and partner remittance obligations.
Bottom-up rollups the platform should natively support
- Per product instance
- Per draw or invoice advance
- Per customer and counterparty
- Per segment and campaign
- Per funding source
- Per salesperson or channel
- Per accounting period or close snapshot
- Per policy version
- Per legal entity and currency
- Per partner program
- Per risk tier
- Per geography and industry
Margin allocation and reserve logic
YieldForge should support not just gross margin calculation, but also margin allocation. A dedicated allocation engine should retain required profitability, top up reserves, fund incentive pools, and track campaign distributions using a clear waterfall and reversible ledger entries.
Example margin waterfall
1. Calculate gross margin
2. Retain minimum profitability threshold
3. Top up loss reserve to target balance
4. Apply partner share or treasury transfer if relevant
5. Allocate excess margin into campaign pools
6. Track consumption, clawbacks, and remaining balanceControls & evidence
Support funding partners, auditors, and strong internal governance
The same engine that helps finance should also make external reporting easier. YieldForge should generate point-in-time evidence from immutable snapshots, not from ad hoc spreadsheets reconstructed after the fact.
Reporting for funding partners
- Asset tape and borrowing base views
- Eligibility and ineligibility reporting
- Concentration, aging, and delinquency metrics
- Collections, remittances, substitutions, and repurchases
- Covenant calculations and pool utilization
- Scheduled exports and API delivery with report versioning
What auditors will need
- Immutable quote, draw, and funding snapshots
- Policy change history and approval evidence
- Rerunnable as-of reports for closed periods
- Charge derivation from raw event history
- Funding allocation and billing tie-outs
- Evidence packs for sampled transactions
Governance requirements
Pricing as code
Policies, incentives, segment definitions, and constraints should be versioned, testable, reviewable, and deployable with effective dates.
Approval workflows
Large policy changes, exception pricing, overlapping segment definitions, and margin floor overrides should require explicit approvals.
Structured adjustments
Waivers, corrections, reversals, write-offs, and goodwill credits should be controlled entries with reasons and audit history.
Developer experience
Developer-first by default
YieldForge should be easy to integrate, easy to test, and safe to evolve. Upstream systems should map into canonical request shapes, while the engine returns structured outputs that remain useful for finance and customers.
API principles
- Authenticated service-to-service APIs
- Versioned request and response schemas
- Idempotency for quote creation and stateful commands
- Explicit as-of timestamps for deterministic evaluation
- Machine-readable explainability and line items
- Stable correlation IDs and traceability metadata
Canonical object model
- Facility
- Draw or obligation
- Charge definition
- Accrual model
- Billing item
- Funding source and allocation
- Margin allocation entry
- Report definition and snapshot
Illustrative API shape
POST /v1/prices:compute
POST /v1/quotes
POST /v1/facilities/{facility_id}/draws
POST /v1/accruals:run
POST /v1/billing-cycles/{cycle_id}:close
POST /v1/funding-allocations:run
POST /v1/margin-allocations:run
GET /v1/quotes/{quote_id}/explanations/customer
GET /v1/reports/gross-margin?group_by=segment,customer,facilityWhat a strong output should contain
Commercial answer
Quoteable amount, line items, schedule assumptions, locked versus floating components, and customer-facing disclosures.
Policy trace
Matched segments, incentives evaluated, rules applied, caps or floors hit, and market references used.
Operational metadata
Engine version, policy versions, market snapshot IDs, correlation ID, and timing metadata for reproducibility.
Success measures
How to know YieldForge is working
A good pricing platform should improve commercial speed, reduce finance friction, and make economics easier to trust. The right scorecard spans engineering, finance, sales, and capital markets.
Commercial and product outcomes
- Faster quote turnaround
- Higher quote conversion
- Lower exception handling time
- Better campaign and segment performance visibility
- Less margin leakage from manual pricing
Finance and control outcomes
- Shorter close and reconciliation cycles
- Fewer billing disputes and overcharge surprises
- Cleaner funding partner reporting
- Faster audit evidence production
- Reliable bottom-up gross margin analytics
What else should be included as the platform matures?
- Revenue recognition and accounting mapping
- Multi-currency billing and FX remeasurement
- Collections and recovery integrations
- Contract amendments and restructures
- Simulation, backtesting, and policy impact analysis
- Role-based entitlements and segregation of duties
- Customer document generation and statement delivery
- Negative-margin and stale-data kill switches
What makes YieldForge different from simpler pricing tools?
Simpler tools often answer only one question: “What rate should we quote?” YieldForge answers the harder questions too: “How should we bill based on real usage?”, “Which funding source paid for this exposure?”, “Why did realized margin differ from quoted margin?”, and “Can finance, partners, and auditors reproduce all of it later?”