# Cash Conversion Cycle

`D18-F01-A03` · Fundamental Analysis and Valuation → Statement Ratios · archetype `record-transform` · difficulty 3/5 · verification **verified**

Full page: https://docs.thefintechbuilder.com/fundamental-analysis-and-valuation/statement-ratios/cash-conversion-cycle/
Agent skill: `npx skills add IslamBaraka90/Fintech-Algorithms-Library` — https://docs.thefintechbuilder.com/guides/agent-skill/

## Install and import

```bash
npm install fintech-algorithms
```

```ts
import { cashConversionCycle } from "fintech-algorithms/fundamental-analysis-and-valuation/statement-ratios/cash-conversion-cycle";
```

## Signature

```ts
cashConversionCycle(input)
```

Turns average receivables, inventory and trade payables into days sales outstanding, days inventory outstanding and days payables outstanding over a stated day count, then reports the cash conversion cycle as DIO plus DSO minus DPO.

## Parameters

| Name | Type | Required | Notes |
| --- | --- | --- | --- |
| `input` | `{ revenue: number; cost_of_goods_sold: number; day_count: number; beginning_receivables: number; ending_receivables: number; beginning_inventory: number; ending_inventory: number; beginning_trade_payables: number; ending_trade_payables: number }` | yes | A plain object. `revenue` scales DSO while `cost_of_goods_sold` scales DIO and DPO; `day_count` is the number of days the period is annualized over. The three balance pairs — `beginning_receivables` and `ending_receivables`, `beginning_inventory` and `ending_inventory`, `beginning_trade_payables` and `ending_trade_payables` — are each averaged. Every key must be a finite number. |

## Returns

`{ average_receivables: number; average_inventory: number; average_trade_payables: number; days_sales_outstanding: number | null; days_inventory_outstanding: number | null; days_payables_outstanding: number | null; cash_conversion_cycle_days: number | null; state: string; reason: string }`

`average_receivables`, `average_inventory` and `average_trade_payables` are always emitted. `days_sales_outstanding` divides average receivables by revenue, `days_inventory_outstanding` and `days_payables_outstanding` divide by cost of goods sold, and each is multiplied by `day_count`; `cash_conversion_cycle_days` sums DIO and DSO and subtracts DPO. When revenue or cost of goods sold is not positive the four day figures are `null`, `state` is `not-meaningful` and `reason` is `nonpositive-revenue` or `nonpositive-cogs`; otherwise `state` is `negative-cycle` for a cycle below zero or `calculated`, with `reason` `dio-plus-dso-minus-dpo`.

## Errors

- When any of the nine inputs is not a finite number — throws RangeError
- When day_count is zero or negative — throws RangeError
- When any receivables, inventory or trade payables balance is negative — throws RangeError

## Complexity

Time `O(1)`, space `O(1)`.

## Worked example

This is the worked example published in the article, replayed by the test suite on every run. The output cannot drift.

### Input

`input`:

```json
{
  "revenue": 2400,
  "cost_of_goods_sold": 1440,
  "beginning_receivables": 280,
  "ending_receivables": 320,
  "beginning_inventory": 340,
  "ending_inventory": 380,
  "beginning_trade_payables": 200,
  "ending_trade_payables": 240,
  "day_count": 365
}
```

### Call

```ts
cashConversionCycle(input)
```

### Returns

object with 9 fields: average_receivables, average_inventory, average_trade_payables, days_sales_outstanding, days_inventory_outstanding, days_payables_outstanding, cash_conversion_cycle_days, state, …

```json
{
  "average_receivables": 300,
  "average_inventory": 360,
  "average_trade_payables": 220,
  "days_sales_outstanding": 45.625,
  "days_inventory_outstanding": 91.25,
  "days_payables_outstanding": 55.763888888889,
  "cash_conversion_cycle_days": 81.111111111111,
  "state": "calculated",
  "reason": "dio-plus-dso-minus-dpo"
}
```

## Other exports

`dupontDecomposition`, `roicCalculation`, `interestCoverageRatio`, `netDebtToEbitda`, `commonSizeStatements`, `calculate`. Every module additionally exports `run` as an alias of its primary
function, and a `meta` object carrying its catalog id, domain, family, shape and article URL.

## Verification and provenance

Tier: **verified** (via input-expected).

The worked example below is the figure published in this algorithm's article, replayed and asserted by the test suite on every build. The arithmetic cannot drift without the build failing.

Both tiers guarantee the signature. Full explanation: https://docs.thefintechbuilder.com/guides/verification/

Generated from the docs.json payload shipped inside fintech-algorithms@0.13.0.
The signature and parameter list are checked against the compiled implementation at build time,
so a description that contradicts the code fails the build rather than reaching this file.

## Links

- Article (how it works, step by step): https://thefintechbuilder.com/fundamental-analysis-and-valuation/statement-ratios/cash-conversion-cycle/
- Implementation source: https://github.com/IslamBaraka90/Fintech-Algorithms-Library/blob/main/src/fundamental-analysis-and-valuation/statement-ratios/cash-conversion-cycle/impl.ts
- Package on npm: https://www.npmjs.com/package/fintech-algorithms
- Domain index for agents: https://docs.thefintechbuilder.com/fundamental-analysis-and-valuation/llms.txt