anchor.diff:  ----
   
   
  -As expected we see one paument for the parent invoice and no payment for the child.
  +As expected we see one payment for the parent invoice and no payment for the child.
   
   == Conclusion
   
  -There is a lot more to demo (regarding dunning, invoice adjsutment, ...), but this should provide a highlight of what the feature is about. Note that this is a new feature in 0.18 and as such it should be seen as a Beta (you are responsible to verify it works accordingly to your use case, load, ...).
  +There is a lot more to demo (regarding dunning, invoice adjustment, ...), but this should provide a highlight of what the feature is about. Note that this is a new feature in 0.18 and as such it should be seen as Beta (you are responsible to verify it works accordingly to your use case, load, ...).
   
   In the future, we may want to add the ability to unparent children (feature is not supported yet).
   
  
positive.code: ----
  
  
  If we inspect our DB entries, we see that there a COMMITTED invoice for the child and a DRAFT invoice for the parent:
  
  
  [source,bash]
  
negative.code: 
  Starting with Kill Bill 0.18.x, we have introduced support of HA (Hierarchical Accounts), and so in this tutorial we will review first what the feature is about, and then explore how it works and which apis to use.
  
  Let's review first what we have prior to introducing the HA feature: In the Kill Bill terminology, a customer will be represented as a Kill Bill `Account`, and such `Account` will then be invoiced based on its current subscriptions and one-off charges. Payments will also be made by using the default payment method associated with the `Account`.
  
  The idea with the HA feature is to delegate some of the payment operations associated to an `Account` to a `parent Account`. Some typical use case for the feature are:
  
  * Affiliate model: In the affiliate model, payments associated to some customers are made through the `parent Account` but each individual `Account` will manage its own subscriptions and will have access to the associated invoices.
  * Sub-Organization: In large organizations, it is common to see sub organizations that work independently, and yet parent organization is responsible for the payments.
  
  The new HA feature allows for the following:
  
  * Ability to set an `Account` as the child of another `Account`
  * Ability to specify on an `Account` that it will be responsible for paying its own invoice (current behaviour)
  * Ability to specify on an `Account` that the parent will be responsible for the payments
  