# AIZEN Business Glossary

Document status: reference. Language: en.
Updated: 2026-11-02. Schema: 1.1.0.
Live data: no.

## Interpretation

- current: An existing label or attribute; its business meaning may still need confirmation.
- reference: A working business definition, not a claim of formal approval.
- needs_decision: True flags an unresolved threshold, source conflict, policy, or entity mapping. Inclusion preserves a useful term without adopting an unverified rule; false does not establish approval.
- numeric_policy: Thresholds and formulas are definitions or working policies, not observed warehouse KPI results.
- aliases: Equivalent names or existing UI labels. search_keywords are related lookup terms, not synonyms or policy mappings.
- entity: The entity or domain described by a term; counting units, cohorts, and denominators still follow its definition.
- reporting_conventions: Fleet and DPD conventions are source-specific. The dashboard uses snapshot DEFAULT buckets and an ACTIVE, trailing-seven-day, non-DEFAULT earning numerator. Calendar-day DPD and report-date-only earning are separate conventions; do not silently substitute them.
- counting_units: Fleet counts use unique vehicle IDs. Person, account, application, contract, vehicle, and event counts are distinct. Repeat applications count as separate applications, not automatically separate people or handovers.
- reconciliation: With complete coverage at one cutoff: Eligible Fleet = Earning Eligible Vehicles + Previously-Handed-Over Idle; Total Idle = Never-Handed-Over Idle + Previously-Handed-Over Idle. Groups are mutually exclusive within their population; breakdowns equal totals.
- source_status: Source observations are pinned code or query definitions, not production verification. PRD status Done is document metadata, not proof of deployment or policy approval.

Stable term IDs identify definitions across formats. Related IDs reference other terms in this document.

## Business & ownership

Who we serve, who owns the asset, and who funds it.

### B2B

ID: business-b2b | Entity: commercial_structure | Type: definition
Group: business / Business relationship
Origin: reference | Needs decision: no
Definition: Electric vehicles supplied at scale to business clients through rental or RTO arrangements.
Note: Monthly invoicing is a repayment process. Program and commercial arrangement, including a genuine sale-and-leaseback, remain separate classifications.
Aliases: Business-to-Business
Search keywords (not synonyms): business to business; corporate
Implementation context: The recorded VehicleType enum includes MOTORCYCLE, CAR, and TRUCK. State the actual vehicle-type coverage of each report; enum support alone does not establish a deployed fleet.

### B2C

ID: business-b2c | Entity: commercial_structure | Type: definition
Group: business / Business relationship
Origin: reference | Needs decision: no
Definition: Rent-to-Own or Rent Only provided directly to individual customers.
Note: B2C vehicles remain registered under AIZEN during the contract. Any ownership transfer is handled separately after the contractual requirements are fulfilled.
Aliases: Business-to-Consumer
Search keywords (not synonyms): business to consumer; retail

### B2B2C

ID: business-b2b2c | Entity: commercial_structure | Type: definition
Group: business / Business relationship
Origin: reference | Needs decision: no
Definition: An intermediary-based commercial relationship connecting business partners with individual customers.
Note: RF remains a B2B2C program in the business taxonomy. Some reports place RF under a B2C reporting segment; do not add both classifications together.
Implementation context: Dashboard segment_of maps RF-prefixed program names to B2C RF. This reporting label does not change the business-model decision.

### Sale-and-Leaseback

ID: business-sale-and-leaseback | Entity: commercial_structure | Type: definition
Group: business / Commercial arrangement
Origin: reference | Needs decision: no
Definition: AIZEN purchases assets from a seller and leases those assets back to that same seller.
Note: The seller becomes the lessee. Ordinary purchases from an OEM followed by B2B rental or B2C RTO are not S&L.
Aliases: SLB; S&L; Sale and Leaseback
Search keywords (not synonyms): SLB; S&L; sale and leaseback

## Program types

The product terms, independent of the customer segment.

### Rent Only (Rental)

ID: programs-rental | Entity: product | Type: definition
Group: programs / Product definitions
Origin: reference | Needs decision: no
Definition: Use of a vehicle for rental payments, with return of the vehicle at program completion rather than an ownership-transfer entitlement.
Note: The SOP calls this Rent Only. It describes a manual Finance billing/payment process for Rent Only; do not assume the RTO automatic daily-billing process applies unchanged.
Aliases: Rent; Rental; Rent Only
Search keywords (not synonyms): Rent

### RTO

ID: programs-rto | Entity: product | Type: definition
Group: programs / Product definitions
Origin: reference | Needs decision: no
Definition: Rent-to-Own: a program allowing a customer or client to obtain ownership after fulfilling the agreed contractual requirements.
Note: For B2C, the SOP separates final repayment, document title transfer, document handover, deposit return, and account closure. B2B RTO follows its own agreement; payment completion alone does not prove legal transfer.
Aliases: Rent-to-Own
Search keywords (not synonyms): rent to own

### RF (Retail Financing)

ID: programs-rf | Entity: product | Type: definition
Group: programs / Product definitions
Origin: reference | Needs decision: no
Definition: Retail Financing: a B2B2C program in which AIZEN acts as an intermediary and a financing institution (Multi Finance) assesses credit and approves financing.
Note: Affiliate Partners may provide leads, wallet deductions, and repayment reports under their agreement. Wallet deduction, remittance to AIZEN, and repayment to Multi Finance are separate events; legal ownership is recorded separately.
Aliases: RF; Retail Financing
Search keywords (not synonyms): Bukopin
Implementation context: Dashboard reporting groups this program as B2C RF. Reconcile program and business-model populations before comparing B2C and B2B2C totals.

## Vehicles

Separate operational status, recovery progress, and remote lock.

### Vehicle ACTIVE

ID: vehicle-vehicle-active | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: no
Definition: An existing vehicle status indicating active use under source-system rules.
Note: Does not independently prove earning, payment quality, or physical possession.

### READY_TO_HANDOVER

ID: vehicle-ready-to-handover | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: yes
Definition: A vehicle available for the handover workflow after the required operational checks.
Note: Credit Connect uses this status for handover creation and after eligible QC or repair completion. It does not by itself confirm a reservation or a universal “Ready to Rent” classification.
Search keywords (not synonyms): ready to handover; ready to rent
Related IDs: vehicle-in-qc, application-handover-pending

### IN_REPAIR

ID: vehicle-in-repair | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: no
Definition: An existing status for vehicles undergoing repair or maintenance.
Note: In Credit Connect, service completion returns the vehicle to ACTIVE or READY_TO_HANDOVER based on its history before QC.
Aliases: Under Repair
Search keywords (not synonyms): under repair; maintenance
Related IDs: vehicle-in-qc, vehicle-ready-to-handover

### IN_QC

ID: vehicle-in-qc | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: yes
Definition: A vehicle undergoing quality inspection before return to use or preparation for handover.
Note: In Credit Connect, QC can lead to repair, ACTIVE, or READY_TO_HANDOVER depending on inspection and prior history. Reporting it as repair or idle still needs an agreed mapping.
Aliases: Quality Control; QC
Search keywords (not synonyms): quality control; QC
Related IDs: vehicle-in-repair, vehicle-ready-to-handover

### INACTIVE vehicle

ID: vehicle-inactive-vehicle | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: yes
Definition: An existing vehicle status requiring a more specific reason.
Note: Does not by itself establish availability, retirement, loss, or customer possession.

### PENDING vehicle

ID: vehicle-pending-vehicle | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: yes
Definition: An existing vehicle status whose operational meaning needs confirmation.
Note: Separate from PENDING_COLLECTION, which explicitly means a collection request. PENDING alone does not justify excluding a vehicle from owned stock.
Related IDs: vehicle-pending-collection

### PENDING_COLLECTION

ID: vehicle-pending-collection | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: no
Definition: A vehicle flagged for collection, before collection work starts.
Note: In Credit Connect, Request Collection sets this status; Start Collection moves it to IN_COLLECTION. Neither confirms that the vehicle has been recovered.
Aliases: Pending Collection
Search keywords (not synonyms): collection request; permintaan penarikan
Related IDs: vehicle-in-collection, handover-physical-vehicle-recovery

### IN_COLLECTION

ID: vehicle-in-collection | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: yes
Definition: Vehicle collection or recovery work is in progress.
Note: Credit Connect can mark the linked contract CHURNED when collection starts. This status alone does not confirm physical recovery; receipt evidence is still needed.
Related IDs: vehicle-pending-collection, handover-physical-vehicle-recovery, contract-churned

### Vehicle PAID_OFF

ID: vehicle-vehicle-paid-off | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: no
Definition: A vehicle carrying the source system’s paid-off financial label.
Note: Verify settlement against the contract. This label alone does not establish legal ownership transfer.
Related IDs: contract-completed, contract-b2c-rto-program-completion

### Remote Unit Lock

ID: vehicle-remote-unit-lock | Entity: vehicle_control | Type: definition
Group: vehicle / Vehicle controls
Origin: reference | Needs decision: no
Definition: An instruction to lock a vehicle remotely through its IoT provider.
Note: Operational vehicle status, reported lock state, and command progress are separate. Sending a command does not confirm the vehicle is locked.
Aliases: Remote Lock
Search keywords (not synonyms): LOCKED; UNLOCKED; IoT; kunci jarak jauh
Implementation context: VehicleRemoteLockCommandStatus: PENDING, IN_PROGRESS, SUCCEEDED, FAILED, TIMED_OUT. These values describe command execution; VehicleLockStatusEnum separately records LOCKED/UNLOCKED. Preserve provider/state evidence before asserting a physical lock.
Related IDs: vehicle-locked, vehicle-in-collection, handover-physical-vehicle-recovery

### Vehicle LOCKED

ID: vehicle-locked | Entity: vehicle | Type: status
Group: vehicle / Current statuses
Origin: current | Needs decision: no
Definition: The LOCKED operational label on a vehicle record.
Note: It is separate from the reported LOCKED/UNLOCKED lock state and from the progress of a remote command.
Implementation context: VehicleStatusEnum retains LOCKED; VehicleLockStatusEnum and VehicleRemoteLockCommandStatus are separate fields and records.
Related IDs: vehicle-remote-unit-lock

## Contracts

Keep lifecycle separate from payment risk and exit reasons.

### COMPLETED

ID: contract-completed | Entity: contract | Type: status
Group: contract / Lifecycle
Origin: current | Needs decision: no
Definition: A contract that has fulfilled its contractual completion requirements.
Note: In Credit Connect, completion requires no remaining installments and no unpaid, processing, or partly paid bills. Legal ownership transfer is verified separately.
Related IDs: contract-b2c-rto-program-completion, contract-rf-program-completion

### Contract CHURNED

ID: contract-churned | Entity: contract | Type: status
Group: contract / Lifecycle
Origin: current | Needs decision: yes
Definition: A contract ended through the churn workflow rather than normal contractual completion.
Note: In Credit Connect, an ACTIVE or DEFAULT contract can move to CHURNED. This does not by itself confirm customer blacklisting, debt settlement, or physical vehicle recovery.
Aliases: CHURNED
Search keywords (not synonyms): contract exit; churn; kontrak berakhir
Implementation context: Pinned code moves ACTIVE or DEFAULT contracts to CHURNED. PRD 742883329 uses customer-level Churned/Blacklisted outcomes, while the recorded CustomerStatus enum has ACTIVE/INACTIVE. Keep entity mapping unresolved instead of copying this status to customer records.
Related IDs: contract-completed, customer-customer-blacklisted, handover-physical-vehicle-recovery

### Recorded DEFAULT

ID: contract-recorded-default | Entity: contract | Type: status
Group: contract / Existing values to clarify
Origin: current | Needs decision: yes
Definition: A contract carrying the DEFAULT status in the source system.
Note: Recorded DEFAULT and reporting DEFAULT are separate fields. Thresholds differ across PRDs and reports; neither implies the vehicle is idle or billing has stopped.
Aliases: Contract DEFAULT
Search keywords (not synonyms): contract default; recorded default
Implementation context: Pinned Credit Connect derives DEFAULT from at least four late bills. PRD 385744907 says DPD >2; PRD 19431425 describes 120 hours. These are documented differences, not verified equivalent production rules.
Related IDs: payment-default, payment-dpd, payment-late-bill-count

### B2C RTO Program Completion

ID: contract-b2c-rto-program-completion | Entity: contract_event | Type: definition
Group: contract / Program completion
Origin: reference | Needs decision: no
Definition: The completion workflow covering document title transfer, document collection, deposit return, and borrower-account closure after the final repayment milestone.
Note: Keep settlement, legal transfer, document handover, and account closure as distinct events; do not assume they share one timestamp.

### RF Program Completion

ID: contract-rf-program-completion | Entity: contract_event | Type: definition
Group: contract / Program completion
Origin: reference | Needs decision: no
Definition: The RF completion process in which final installment repayment is followed by financial-institution notification and BPKB handover.
Note: The SOP assigns BPKB handover to the financial institution; do not substitute the B2C RTO completion workflow.

### Contract ACTIVE

ID: contract-contract-active | Entity: contract | Type: status
Group: contract / Current statuses
Origin: current | Needs decision: no
Definition: A contract currently in force.
Note: Payment health is tracked separately: an ACTIVE contract can have overdue bills. Credit Connect records DEFAULT as a separate contract status.
Related IDs: contract-recorded-default, payment-late-bill-count

### Contract BLACKLISTED

ID: contract-contract-blacklisted | Entity: contract | Type: status
Group: contract / Current statuses
Origin: current | Needs decision: yes
Definition: An existing contract status requiring confirmation of its exit and restriction semantics.
Note: Preserve contract history. Do not automatically infer a customer blacklist flag.
Implementation context: PRD 742883329 describes Blacklisted as final; Draft Layer Approval 759300097 allows exceptions. Pinned application approval code can reopen a customer restriction while leaving the historical application BLACKLISTED. Do not infer permanence or propagate flags across entities.
Related IDs: customer-customer-blacklisted

### Contract DRAFT

ID: contract-contract-draft | Entity: contract | Type: status
Group: contract / Current statuses
Origin: current | Needs decision: yes
Definition: A pre-activation contract record.
Note: Credit Connect retains legacy contract-onboarding states. A DRAFT contract record is separate from an application draft or a legal document awaiting signature.

### Legacy Contract Statuses

ID: contract-legacy-statuses | Entity: contract | Type: status
Group: contract / Current statuses
Origin: current | Needs decision: yes
Definition: Contract-level onboarding and older status labels retained alongside the application-led flow.
Note: Always state the entity and source version. Matching names across application and contract records do not prove the same event.
Implementation context: CustomerContractStatus retains INITIATED, IN_REVIEW, SCHEDULING, HANDOVER_PENDING, HANDOVER_PROCESS, REJECTED and SOFT_REJECTED. INACTIVE, PENDING_VERIFICATION, NEED_REVIEW, WAITING_FOR_HANDOVER are deprecated. These enum values are not a universal migration or transition order.

## Customer statuses

Customer record status and restrictions, separate from contract and application progress.

### Customer ACTIVE

ID: customer-customer-active | Entity: customer | Type: status
Group: customer / Current statuses
Origin: current | Needs decision: yes
Definition: A customer record marked ACTIVE in EMMS.
Note: Credit Connect sets this status during handover activation. Contract status, payment health, and login permissions are separate.
Related IDs: contract-contract-active, customer-customer-inactive

### Customer INACTIVE

ID: customer-customer-inactive | Entity: customer | Type: status
Group: customer / Current statuses
Origin: current | Needs decision: yes
Definition: A customer record marked INACTIVE in EMMS.
Note: An INACTIVE customer can still have a lead or blacklist flag. This status alone does not establish contract history or login permissions.
Related IDs: customer-customer-active, customer-customer-blacklisted

### Customer Blacklisted

ID: customer-customer-blacklisted | Entity: customer | Type: status
Group: customer / Current statuses
Origin: current | Needs decision: yes
Definition: A customer restriction flag with a reason, effective date, and review or removal policy.
Note: Not a lifecycle state; do not automatically derive it from contract or application labels.
Aliases: is_blacklisted
Search keywords (not synonyms): is_blacklisted; blacklist
Implementation context: PRD 742883329 describes Blacklisted as final; Draft Layer Approval 759300097 allows exceptions. Pinned application approval code can reopen a customer restriction while leaving the historical application BLACKLISTED. Do not infer permanence or propagate flags across entities.

## Application & acquisition

Distinguish people, applications, workflow stages, and cohorts.

### IN_REVIEW

ID: application-in-review | Entity: application | Type: status
Group: application / Application workflow
Origin: current | Needs decision: no
Definition: An application in verification and video review after credit approval in the application-led flow.
Note: SCHEDULING follows approval of submitted video or a NOT_REQUIRED video path; credit approval alone does not confirm handover readiness.
Search keywords (not synonyms): application workflow
Implementation context: Video state is separate from ApplicationStatus: NOT_STARTED, NOT_REQUIRED, WAITING_VIDEO, SUBMITTED, RETAKE_REQUIRED. A retake can leave the application IN_REVIEW.

### SCHEDULING

ID: application-scheduling | Entity: application | Type: status
Group: application / Application workflow
Origin: current | Needs decision: no
Definition: An application eligible for handover scheduling.
Note: A reserved slot does not itself confirm commitment-fee payment or physical delivery.
Search keywords (not synonyms): application workflow

### HANDOVER_PENDING

ID: application-handover-pending | Entity: application | Type: status
Group: application / Application workflow
Origin: current | Needs decision: yes
Definition: In Credit Connect’s application-led flow, an application awaiting handover after commitment-fee settlement and schedule reservation.
Note: A pending handover is not a completed delivery.
Search keywords (not synonyms): application workflow
Implementation context: Pinned application code settles the booking fee with a reserved schedule before HANDOVER_PENDING. PRDs differ on whether deposit falls due in HANDOVER_PENDING or HANDOVER_PROCESS; the mobile application flow exposes its deposit card in HANDOVER_PROCESS.

### HANDOVER_PROCESS

ID: application-handover-process | Entity: application | Type: status
Group: application / Application workflow
Origin: current | Needs decision: yes
Definition: An application undergoing handover processing.
Note: Not a completed physical handover.
Search keywords (not synonyms): application workflow
Implementation context: Pinned application code confirms the deposit in HANDOVER_PROCESS after commitment-fee settlement. PRDs place the deposit gate at different stages; do not infer one universal due date from the status.

### CONTRACT_GENERATED

ID: application-contract-generated | Entity: application | Type: status
Group: application / Application workflow
Origin: current | Needs decision: no
Definition: An application that has been linked to its newly created customer contract.
Note: Keep the application’s history separate from contract servicing and physical-delivery evidence.
Search keywords (not synonyms): application workflow

### REJECTED

ID: application-rejected | Entity: application | Type: status
Group: application / Assessment outcome
Origin: current | Needs decision: no
Definition: An application declined following assessment.
Note: Keep customer restrictions separate.
Search keywords (not synonyms): application workflow

### DRAFT application

ID: application-draft-application | Entity: application | Type: status
Group: application / Current statuses
Origin: current | Needs decision: no
Definition: An application saved before submission.
Note: This is an application record, not a signed contract or a count of unique people.
Implementation context: Submission moves DRAFT to INITIATED. Customer ID, Application ID, and Contract ID identify different records; one customer can have repeat applications.

### INITIATED

ID: application-initiated | Entity: application | Type: status
Group: application / Current statuses
Origin: current | Needs decision: no
Definition: A submitted application awaiting credit assessment.
Note: It is not an active contract. Approval in the application-led flow moves it to IN_REVIEW.
Related IDs: application-draft-application, application-in-review

### SOFT_REJECTED

ID: application-soft-rejected | Entity: application | Type: status
Group: application / Current statuses
Origin: current | Needs decision: yes
Definition: A rejection-related application value retained in the source system.
Note: The schema marks it deprecated for new data, but recorded code paths and web filters still use it. Do not infer reapplication eligibility.
Implementation context: Pinned application.entity.ts still assigns this value in rejection paths. Runtime use depends on the route; schema deprecation alone does not establish that writes have stopped.

### Application BLACKLISTED

ID: application-application-blacklisted | Entity: application | Type: status
Group: application / Current statuses
Origin: current | Needs decision: yes
Definition: An application recorded as blacklisted or restricted.
Note: This historical application status is separate from the customer’s current restriction flag.
Implementation context: OPEN_BLACKLIST can reopen the customer as a lead while the old application remains BLACKLISTED. PRD finality and exception rules differ.
Related IDs: customer-customer-blacklisted, contract-contract-blacklisted

## Handover & recovery

Separate physical events, documents, and ledger entries.

### BAST

ID: handover-bast | Entity: handover_document | Type: definition
Group: handover / Delivery & documentation
Origin: reference | Needs decision: no
Definition: A document acknowledging a specified handover or receipt between named parties.
Note: The SOP uses BAST for OEM-to-AIZEN receipt, customer/client vehicle handover, collected-unit warehouse receipt, and BPKB handover. A BAST record is not automatically a new customer deployment.
Aliases: Berita Acara Serah Terima
Search keywords (not synonyms): serah terima; handover document
Related IDs: handover-b2c-billing-start, handover-physical-vehicle-recovery

### Physical Vehicle Recovery

ID: handover-physical-vehicle-recovery | Entity: vehicle_event | Type: definition
Group: handover / Recovery & re-rental
Origin: reference | Needs decision: no
Definition: Confirmed physical retrieval of a vehicle, with a recovery date and receipt evidence.
Note: Record the recovery date and receiving custodian. In RF, recovery can precede a later handover to AIZEN; a contract exit, remote lock, or collection initiation does not confirm physical recovery.
Related IDs: vehicle-in-collection, vehicle-remote-unit-lock, handover-bast

### B2C Billing Start

ID: handover-b2c-billing-start | Entity: contract_event | Type: definition
Group: handover / Delivery & documentation
Origin: reference | Needs decision: no
Definition: The effective start date of a B2C contract’s billing schedule.
Note: Use the contract’s billing start date. Physical handover, the first chargeable installment, and cash receipt can fall on different dates.
Related IDs: handover-bast, payment-initial-paid-billing, payment-cash-received

### Multi Finance Disbursement

ID: handover-multi-finance-disbursement | Entity: financing_event | Type: definition
Group: handover / Financing & delivery
Origin: reference | Needs decision: no
Definition: Release or activation of financing by Multi Finance under the relevant facility.
Note: The SOP places B2C unit disbursement on handover day and B2B financing activation one day after client delivery. Do not use one universal disbursement-to-handover date rule.

### Physical Handover

ID: handover-physical-handover | Entity: vehicle_event | Type: definition
Group: handover / Handover events
Origin: reference | Needs decision: no
Definition: Confirmed physical delivery of a vehicle to an individual customer or corporate client.
Note: First handover is the vehicle’s first customer delivery; repeat handover is a later customer delivery. Warehouse or city transfers are separate events. Use the actual event date and location; later moves do not rewrite history.
Aliases: Customer Handover
Implementation context: Record the event type and unique vehicle ID. Repeat applications or contracts do not themselves prove another physical handover.
Related IDs: handover-bast, fleet-eligible-fleet

### Voluntary Return

ID: handover-voluntary-return | Entity: vehicle_event | Type: definition
Group: handover / Return & recovery
Origin: reference | Needs decision: no
Definition: A customer voluntarily hands the vehicle back to AIZEN or its designated custodian.
Note: Record physical receipt separately from the reason for return. This is distinct from repossession and does not itself settle debt or close the contract.
Related IDs: handover-physical-vehicle-recovery, contract-churned

### Takeover (RTO Unit)

ID: handover-takeover | Entity: vehicle_event | Type: definition
Group: handover / Handover events
Origin: reference | Needs decision: yes
Definition: Reuse of a previously handed-over vehicle under a subsequent customer agreement.
Note: A reuse proxy is not proof of a new physical handover or a universally agreed RTO billing rule.
Aliases: Take over
Implementation context: Dashboard V04 requires handover rank ≥2 plus handover within 45 days of the selected contract entry date. PRDs 571637763/374669313 use different <30/>30-day billing rules and leave exactly 30 days undefined. Legacy dbt reuse cohorts also differ; do not merge these definitions.
Related IDs: handover-physical-handover

## Payment & delinquency

Separate bills, cash, balances, and payment-risk events.

### Chargeable Billing

ID: payment-chargeable-billing | Entity: contract_payment | Type: definition
Group: payment / Billing, cash & balances
Origin: reference | Needs decision: no
Definition: Bills or bill components that create a customer payment obligation under the applicable program rules.
Note: Use actual payable components: free billing can leave fees due. Chargeable billing is a payment obligation, not cash received or accounting revenue.
Related IDs: payment-billing, payment-cash-received, payment-free-billing, payment-hold-billing

### Cash Received

ID: payment-cash-received | Entity: payment | Type: definition
Group: payment / Billing, cash & balances
Origin: reference | Needs decision: no
Definition: Actual cash receipts during the reporting period, measured by receipt date.
Note: Separate installments, deposits, fees, and refunds. In RF, a driver-wallet deduction is distinct from the AP remittance received by AIZEN.
Aliases: Cash Collected; Cash Receipts
Search keywords (not synonyms): penerimaan kas
Related IDs: payment-chargeable-billing, payment-settled-billing

### Settled Billing

ID: payment-settled-billing | Entity: contract_payment | Type: definition
Group: payment / Billing, cash & balances
Origin: reference | Needs decision: no
Definition: Bills fully resolved through payments or valid adjustments.
Note: Not equivalent to cash received: receipt and bill dates differ, and adjustments may be noncash.
Aliases: Settled Bills
Search keywords (not synonyms): paid bills; settled bills
Related IDs: payment-cash-received, payment-outstanding-balance

### Outstanding Balance

ID: payment-outstanding-balance | Entity: contract_payment | Type: definition
Group: payment / Billing, cash & balances
Origin: reference | Needs decision: no
Definition: Remaining obligations after allocated payments and valid adjustments.
Note: Includes both overdue and not-yet-due amounts.
Related IDs: payment-arrears, payment-settled-billing

### Arrears

ID: payment-arrears | Entity: contract_payment | Type: definition
Group: payment / Billing, cash & balances
Origin: reference | Needs decision: no
Definition: The overdue portion of outstanding balance after allocated payments and valid adjustments.
Note: Do not assume the full original bill remains due when partial allocations exist.
Related IDs: payment-outstanding-balance, payment-dpd

### Daily Deduction Engine (RF)

ID: payment-daily-deduction-engine | Entity: payment_process | Type: definition
Group: payment / RF repayment flows
Origin: reference | Needs decision: no
Definition: The RF process in which the Affiliate Partner arranges driver-wallet deductions and reports repayment activity to AIZEN.
Note: Credit Connect also uses DDE for GoPay autocharge. That flow, RF partner-wallet deductions, and AP remittances are separate.
Aliases: DDE
Related IDs: payment-ap-remittance-to-aizen, payment-aizen-repayment-to-multi-finance

### AP Remittance to AIZEN

ID: payment-ap-remittance-to-aizen | Entity: payment | Type: definition
Group: payment / RF repayment flows
Origin: reference | Needs decision: no
Definition: Payment from the Affiliate Partner to AIZEN for RF customers under the monthly remittance process.
Note: This is separate from the daily customer-wallet deductions and from onward payment to Multi Finance.

### AIZEN Repayment to Multi Finance

ID: payment-aizen-repayment-to-multi-finance | Entity: payment | Type: definition
Group: payment / RF repayment flows
Origin: reference | Needs decision: no
Definition: AIZEN payment to the financing institution under the financing schedule.
Note: This is AIZEN’s financing outflow, not customer installment cash received.

### Backcharge

ID: payment-backcharge | Entity: billing_adjustment | Type: definition
Group: payment / B2B invoicing
Origin: reference | Needs decision: no
Definition: An adjustment that reduces the amount to be charged on the B2B client invoice under the SOP.
Note: Record its reason and supporting agreement. Do not automatically treat it as cash received or a refund transaction.

### Commitment Fee

ID: payment-commitment-fee | Entity: payment | Type: definition
Group: payment / Onboarding payments
Origin: reference | Needs decision: yes
Definition: An onboarding fee associated with confirming a handover reservation.
Note: Often called booking fee, but labels overlap with “deposit” in PRDs and mobile screens. No universal amount or refund promise follows from the label.
Aliases: CF
Search keywords (not synonyms): tanda jadi; Deposit 1st term; Booking fee; deposit 1st term
Implementation context: Identify charge purpose and stage using BillingDetailTypeEnum: COMMITMENT_FEE, DEPOSIT, BILLING, ADDITIONAL_FEE, REFUND, GENERAL. PRDs conflict on naming, timing, and refundability; mobile deposit copy says non-refundable while some PRDs allow a refund. The type code identifies the charge, not its refund policy.
Related IDs: payment-deposit, application-handover-pending

### Deposit

ID: payment-deposit | Entity: payment | Type: definition
Group: payment / Onboarding payments
Origin: reference | Needs decision: yes
Definition: An upfront customer payment recorded separately from the booking or commitment fee and recurring installments.
Note: Deposit, DP, and booking-fee labels vary by source. Identify the exact charge type, program, and stage before applying refund or deduction terms.
Search keywords (not synonyms): DP; down payment; uang muka; uang jaminan; Deposit 2nd term
Implementation context: Identify charge purpose and stage using BillingDetailTypeEnum: COMMITMENT_FEE, DEPOSIT, BILLING, ADDITIONAL_FEE, REFUND, GENERAL. PRDs conflict on naming, timing, and refundability; mobile deposit copy says non-refundable while some PRDs allow a refund. The type code identifies the charge, not its refund policy.
Related IDs: payment-commitment-fee, payment-initial-paid-billing, contract-b2c-rto-program-completion

### Free Billing

ID: payment-free-billing | Entity: payment | Type: definition
Group: payment / Billing & fees
Origin: reference | Needs decision: no
Definition: Promotional treatment that waives eligible installment charges.
Note: Additional fees may remain due. Credit Connect’s first-sequence complimentary billing follows a separate rule.
Search keywords (not synonyms): Complimentary billing; FREE_BILLING
Related IDs: payment-initial-paid-billing, payment-hold-billing

### Initial-Paid Billing

ID: payment-initial-paid-billing | Entity: payment | Type: definition
Group: payment / Billing & fees
Origin: reference | Needs decision: no
Definition: A program’s initial installment allowance used to cover eligible bills without a new payment on each billing date.
Note: Separate from promotional free billing and Credit Connect’s first-sequence complimentary rule.
Related IDs: payment-free-billing, payment-deposit

### Hold Billing

ID: payment-hold-billing | Entity: billing | Type: definition
Group: payment / Billing & fees
Origin: reference | Needs decision: yes
Definition: A temporary hold on regular installment billing for a specified period.
Note: The Done PRD calls for DPD to stay at its pre-hold value. That is documented intent, not proof of every code path. A hold is not repayment or an arrears waiver.
Aliases: Tunda Bayar; Libur Bayar
Search keywords (not synonyms): billing hold; HOLD_BILLING; ON_HOLD
Implementation context: PRD 658276353 specifies a DPD freeze. Pinned billing code treats ON_HOLD as a hard hold and REQUESTED/APPROVED windows as soft holds. Hard hold wins over program free billing; program free billing wins over soft hold. Request statuses are REQUESTED, APPROVED, ON_HOLD, REJECTED, COMPLETED, EXPIRED, CANCELLED. A submitted request is not the same as an active hold; confirm the effective window and DPD calculation.
Related IDs: payment-stop-billing, payment-stop-accrual, payment-dpd

### Late Bill Count

ID: payment-late-bill-count | Entity: payment | Type: definition
Group: payment / Delinquency
Origin: reference | Needs decision: yes
Definition: The number of unpaid bills that are at least one day overdue.
Note: Count each bill once while a due balance remains, including partial payments. One bill overdue four days is still one bill. First-late-day timing varies by source.
Aliases: Overdue bill count
Implementation context: Pinned Credit Connect counts unpaid rows with per-bill DPD ≥1. PRD 385744907 shifts the first late day to H+2; do not silently apply that delay to every report.
Related IDs: payment-dpd, contract-recorded-default

### DPD (Calendar Days)

ID: payment-dpd | Entity: contract_payment | Type: definition
Group: payment / Delinquency
Origin: reference | Needs decision: yes
Definition: Calendar days since the oldest due date with an unpaid overdue balance, measured at the reporting date; minimum 0.
Note: DPD is 0 when nothing is overdue. Partial payment stays overdue while a due balance remains. Reconstruct balances and allocations at the historical cutoff. Hold-adjusted values and billing-cycle counts are different measures.
Formula: max(0, reporting date − oldest unpaid due date); 0 if no overdue balance
Aliases: Days Past Due; Calendar DPD
Search keywords (not synonyms): DPD; H+2; first late day
Implementation context: The pinned Credit Connect helper computes per-bill calendar aging and separately counts late bills. Other PRDs increment DPD per missed cycle or start the first late day at H+2; neither is a universal calendar-day rule. Read hold treatment and source basis before comparing values.
Related IDs: payment-arrears, payment-late-bill-count, payment-legacy-dpd-label, payment-hold-billing, payment-default

### Billing

ID: payment-billing | Entity: bill | Type: definition
Group: payment / Billing & payment timing
Origin: reference | Needs decision: no
Definition: A record of an amount due, its due date, and payment status.
Note: Payments and allocations are separate transactions. A bill can receive several partial payments; payment date does not replace due date.
Related IDs: payment-chargeable-billing, payment-settled-billing, payment-dpd

### Default (Reporting)

ID: payment-default | Entity: contract | Type: definition
Group: payment / Delinquency
Origin: reference | Needs decision: yes
Definition: A contract classified as DEFAULT in the specified reporting snapshot.
Note: State the snapshot and its bucket rules. Calendar DPD ≥4 is a separate glossary convention; it is not a verified equivalent of the dashboard bucket. Default alone does not establish idle or stopped billing.
Aliases: Reporting Default
Implementation context: Dashboard K01 selects dpd_bucket from l1.contract_dpd_snapshot; its query metadata defines DEFAULT as 4+ consecutive unpaid daily billing cycles. K01 does not calculate calendar DPD. PRDs instead describe DPD >2 or 120-hour thresholds; do not harmonize them without a policy decision.
Related IDs: payment-dpd, payment-legacy-dpd-label, contract-recorded-default, payment-late-bill-count

### Stop Billing

ID: payment-stop-billing | Entity: bill | Type: definition
Group: payment / Billing controls
Origin: reference | Needs decision: no
Definition: Suspension or cessation of creating new customer charges from an effective date.
Note: Existing debt remains unless separately settled or adjusted. Default or recovery does not imply billing has stopped; use the actual schedule and effective stop or hold.
Related IDs: payment-hold-billing, payment-stop-accrual, payment-outstanding-balance

### Stop Accrual

ID: payment-stop-accrual | Entity: accounting_policy | Type: definition
Group: payment / Billing controls
Origin: reference | Needs decision: no
Definition: Suspension of accounting revenue recognition under the applicable accounting policy.
Note: This is separate from creating bills and receiving cash. No automatic Default threshold or accounting policy is established by this glossary.
Related IDs: payment-stop-billing, payment-cash-received, payment-chargeable-billing

### Legacy DPD Labels

ID: payment-legacy-dpd-label | Entity: delinquency_measure | Type: definition
Group: payment / Delinquency
Origin: reference | Needs decision: yes
Definition: Source-provided delinquency labels such as DPD 1–3, Near Default 1/2, and Default.
Note: They are categorical labels; do not convert them into calendar days or current snapshot buckets without a verified mapping.
Implementation context: Legacy dbt summaries select the latest payment_order label rather than recalculating elapsed days. PRDs describe missed cycles, an H+2 first late day, or hour-based thresholds; these are distinct bases.
Related IDs: payment-dpd, payment-default

### Contract Billing Status

ID: payment-billing-health | Entity: contract | Type: status
Group: payment / Billing status
Origin: current | Needs decision: no
Definition: A contract’s billing-health field, separate from its lifecycle and individual bill payments.
Note: Recorded values are NORMAL, LATE, SUSPENDED, and COMPLETED. SUSPENDED does not by itself establish contract termination.
Implementation context: BillingStatus belongs to CustomerContract. This field is distinct from CustomerContractStatus and from BillingPaymentStatusEnum on an individual bill; a screen label is not a substitute for the backend field.

### Bill Payment Status

ID: payment-bill-payment-status | Entity: bill | Type: status
Group: payment / Billing status
Origin: current | Needs decision: no
Definition: The recorded settlement state of an individual bill.
Note: UNPAID, PROCESSING, and PARTIAL_PAID remain distinct from PAID. A failed payment attempt does not prove that the bill is settled.
Implementation context: BillingPaymentStatusEnum includes UNPAID, PAID, PROCESSING, PARTIAL_PAID and legacy FAILED (deprecated in the schema). Gateway/transaction attempts have separate states. Do not recode historical FAILED records solely from deprecation comments or a mobile display label.

## Fleet performance

One reporting cutoff, one vehicle population, and an explicit billing proxy.

### Eligible Fleet

ID: fleet-eligible-fleet | Entity: vehicle | Type: definition
Group: fleet / Fleet scope
Origin: reference | Needs decision: yes
Definition: Vehicles in the declared reporting scope with a confirmed customer handover on or before the cutoff, excluding paid-off vehicles.
Note: Use unique vehicles and states effective at the cutoff. Declare treatment of disposed, written-off, and missing units; paid-off exclusion alone does not resolve fleet scope. Unknown exit mapping is a coverage gap, not zero.
Formula: Eligible Fleet = Earning Eligible Vehicles + Previously-Handed-Over Idle
Implementation context: Dashboard V03 counts in-scope B2C vehicles with known cutoff status other than PAID_OFF and a first deployment date. This is a reporting population, not proof of legal ownership. WRITTEN OFF appears in PRD 571637763 but not in the pinned VehicleStatusEnum.
Related IDs: fleet-earning-vehicle, fleet-previously-handed-idle, vehicle-vehicle-paid-off

### Earning Eligible Vehicles

ID: fleet-earning-vehicle | Entity: vehicle | Type: definition
Group: fleet / Earning & utilization
Origin: reference | Needs decision: yes
Definition: Eligible vehicles meeting the declared billing-based earning rule at the reporting cutoff.
Note: Declare the billing window, operational-state rule, and Default treatment. Billing on the report date is a daily convention; a trailing seven-day numerator measures a different window. Neither is cash received or accounting revenue.
Aliases: Earning Vehicle
Implementation context: Dashboard V03 requires ACTIVE at cutoff (using vehicle audit history when needed), prior customer handover, positive chargeable billing dated cutoff minus six days through cutoff, and a linked cutoff snapshot whose bucket is not DEFAULT. These filters differ from the glossary’s earlier report-date-only convention; a lookup window can retain vehicles whose earning has since stopped.
Related IDs: fleet-eligible-fleet, payment-chargeable-billing, payment-cash-received, payment-stop-accrual

### Eligible-Fleet Utilization

ID: fleet-utilization | Entity: vehicle | Type: definition
Group: fleet / Earning & utilization
Origin: reference | Needs decision: yes
Definition: Earning eligible vehicles divided by eligible fleet at the same reporting cutoff.
Note: Use the same scope, unique vehicles, and earning rule on both sides. Never-handed-over stock is outside this denominator. Zero denominator or incomplete coverage means unavailable.
Formula: Earning Eligible Vehicles ÷ Eligible Fleet × 100%
Aliases: Utilization
Implementation context: Dashboard V03 divides revenue_active_units by handed_over_owned_units, not the ACTIVE-only utilization_base_units. Its numerator is ACTIVE, seven-day billed, and non-DEFAULT on the snapshot; the registry labels that definition Agreed. An owned-fleet ratio has a different denominator.
Related IDs: fleet-eligible-fleet, fleet-earning-vehicle, fleet-idle

### Total Idle

ID: fleet-idle | Entity: vehicle | Type: definition
Group: fleet / Idle population
Origin: reference | Needs decision: yes
Definition: Non-paid-off vehicles in the declared reporting scope that do not meet the billing-based earning rule at the cutoff.
Note: Includes never-handed-over and previously-handed-over vehicles under one earning rule. Declare disposal, write-off, and missing-unit treatment. Unknown billing or exit coverage is unavailable, not automatically idle or zero.
Formula: Total Idle = Never-Handed-Over Idle + Previously-Handed-Over Idle
Aliases: Idle
Related IDs: fleet-never-handed-idle, fleet-previously-handed-idle, fleet-earning-vehicle

### Never-Handed-Over Idle

ID: fleet-never-handed-idle | Entity: vehicle | Type: definition
Group: fleet / Idle population
Origin: reference | Needs decision: no
Definition: Idle vehicles with no confirmed customer handover on or before the reporting cutoff.
Note: Exclude paid-off vehicles. Warehouse or city transfers are not customer handovers. Count each vehicle once.
Aliases: Never-Handed Idle
Related IDs: fleet-idle, handover-physical-handover

### Previously-Handed-Over Idle

ID: fleet-previously-handed-idle | Entity: vehicle | Type: definition
Group: fleet / Idle population
Origin: reference | Needs decision: no
Definition: Eligible vehicles not earning under the billing-based rule on the reporting date.
Note: Exclude paid-off vehicles and apply the same fleet scope, cutoff, and earning window as the numerator. Count each vehicle once; never subtract total idle from eligible fleet.
Formula: Eligible Fleet − Earning Eligible Vehicles
Aliases: Previously-Handed Idle
Related IDs: fleet-idle, fleet-eligible-fleet, fleet-earning-vehicle

### Idle Duration

ID: fleet-idle-duration | Entity: vehicle | Type: definition
Group: fleet / Idle time
Origin: reference | Needs decision: no
Definition: Elapsed idle time measured with a stated start event and end event or reporting cutoff.
Note: Total downtime may include recovery, repair, and QC. Ready-to-rent waiting time starts only when readiness is confirmed. State clocks and targets separately for never-handed-over and previously-handed-over vehicles.
Related IDs: fleet-never-handed-idle, fleet-previously-handed-idle, vehicle-ready-to-handover, vehicle-in-repair

## User clarifications already applied

### business-model-taxonomy

Authority: user | Date: 2026-10-27
B2B2C is the newer business model. RF is a program under B2B2C; main models remain B2B, B2C, B2B2C.

### sale-and-leaseback-scope

Authority: user | Date: 2026-10-27
S&L requires leasing purchased assets back to the same seller. Ordinary OEM procurement for B2B rental or B2C RTO is separate.