anchor.diff:  ** Invoice: invoice generation and management (e.g. ability to adjust invoice items) for subscriptions and one-off charges
   ** Payment: payment gateways integration for recurring and one-off payments
   ** Overdue: dunning management (in case of unpaid invoices for instance)
  +* Multi-tenancy: Kill Bill has been designed as a multi-tenant system, meaning **you can run multiple logical instances of Kill Bill with a single server and database** (see this http://killbill.io/blog/subscription-service-using-kill-bill[blog post] which illustrates some of the use cases).
   * Plugins
  +** Ability to easily connect to third party services
  +** Ability to modify behavior of the system to match custom business logic
   
  -Kill Bill supports multi-tenancy, meaning you can run multiple logical instances of Kill Bill with a single server and database (see this http://killbill.io/blog/subscription-service-using-kill-bill[blog post] which illustrates some of the use cases).
   
   
   == Where to Start?
   
  -TODO points to 
  +//TODO points to Getting Started
   
   === Layman's Next Steps
   
  
positive.code: The flow diagram above highlights a couple of important aspects of the system:
  
  1. The creation of the subscription will generate a series of internal events that will lead to the generation of the _invoice_ and its associated _payment_. If needed such behavior can also be configured.
  2. Because of its plugin architecture, it is easy to extend the system by writing plugins. The diagrams above assume the plugins interact with 3rd party systems, but of course all the tax logic could for instnace be implemented in the plugin itself.
  3. Kill Bill offers well defined extension points for these plugins to be highly effective and modify the behavior of the system as needed.
  
  
  
negative.code: ** A *plugin framework* where open-source and proprietary plugins can be added to modify the behavior of the system, and/or to interact with third party systems
  ** A robust persistent *event bus*, that is used both internally and externally (events are visible to plugins and to other services via HTTP push notifications)
  ** An *auditing* framework that keeps track of all the changes that occurred (who?, when?, what?)
  * Core services, each of which exposing its own APIs and publishing bus events, which are consumed by other core services or 
  plugins:
  ** Account
  ** Catalog
  ** Subscription and entitlement
  