anchor.diff:  }
   ----
   
  -In this example, we see that we billed for two units `cell-phone-minutes` and `Mbytes`: For the `cell-phone-minutes`, the quantity recorded for the period was such, that we reached the maxium for tier 1 and started to bill some units for tier 2; for the `Mbytes` units, we billed  everything in the tier 1. The amount reported is the sum of the amount : 40 + 2000 + 100 = 2140.
  +In this example, we have billed for two unit types: `cell-phone-minutes` and `Mbytes`. For `cell-phone-minutes`, the quantity recorded for the period reached the maximum for tier 1 and extended into tier 2. Since we are using the 'ALL_TIER' policy, the amount for each tier is computed separately, giving 40 for tier 1 and 2000 for tier 2. For the `Mbytes` units, all usage remained in tier 1, so a single amount, 100, is computed. The amount reported is the sum of the individual amounts: 40 + 2000 + 100 = 2140.
  +
  +If we were instead using the `TOP_TIER` policy, all usage of `cell=phone-minutes` would be billed at the tier 2 price (20) for a total of 2400, so the aggregate amount reported would be 2500.
   
   ==== Detail Mode
   
   Sometimes it is desirable to output one `USAGE` item per unit type and tier, so in this case the detail for the billing is inside each
  -invoice item -- and the aggregate amount is computed by summing the sum amount. In order to activate this mode, one needs to set
  +invoice item, and the aggregate amount is computed by summing all the amounts. In order to activate this mode, one needs to set
   the system property `org.killbill.invoice.item.result.behavior.mode` to `DETAIL`.
   
   Each of the `USAGE` items will contain the following fields:
   
   * `quantity`: Quantity consumed for the unit (type) and on the given tier
  -* `rate`: We reused the `rate` field normally reserved for the `RECURRING` type to output the price of the tier
  +* `rate`: The `rate` field normally reserved for the `RECURRING` type is used to output the price of the tier
   
   Also, the `itemDetails` json field will provide some additional details:
   
  
positive.code: 
  Missing Usage Data:
  
  Currently it is considered an error to delete past usage data in these past 2 periods, the invoicing system would throw an error and prevent invoicing to happen correctly. If the late missing data is older than these past 2 periods, it is simply ignored.
  
  One can set the system property -- or per-tenant config -- `org.killbill.invoice.readMaxRawUsagePreviousPeriod` to `0` to ignore any past data -- late usage or missing data.
  
  
negative.code: ----
  
  In this example we see that we were invoiced for 2 different units, and this shows the tier details for each unit, and the amount that will be charged.
  Because unit `members` reached tier 3, the amount will be based on the pricing for this tier.
  
  ==== Consumable In Arrear Mode
  
  This mode bills for each unit based on actual usage, using a price determined by the tier(s) reached and by the policy. With the `ALL_TIER` policy, usage within each tier is charged according to the price for that tier. With the `TOP_TIER` policy, all usage is charged according to the price for the highest tier reached. 
  
  We can configure the invoicing system to output one amount per tier (Detail Mode), or a single amount for all tiers (Aggregate Mode). The example below illustrates each mode for the `ALL_TIER` policy.
  
  ==== Aggregate Mode
  
  