The Bill-to-Cash workstream aims to build on the existing positive engagement between GSC members and benefactors, with a specific focus on what members consider “core components” of any bill-to-cash system.
The aims of this workstream are to create:
- A common baseline of expectations from carriers that can become a recommended standard in the community and amongst benefactors
- An opportunity for benefactors to indicate their current capability level (RAG status) against each requirement in the high level requirement document and any “additional” capability not mentioned
- A dedicated workstream and time allotment at upcoming conferences to identify current and future challenges within the carriers, to help benefactors prioritize future development opportunities
- A chance to demonstrate system capability in the form of “worked examples” end-to-end (e.g., a dispute from discovery to resolution) at a future conference
- Benefits for everyone attending the GSC from focused discussions on system capability and helping benefactors to prioritize the most valuable new capability based on members’ recommendations
What we’ve accomplished so far
Built a “High Level Design” requirements document (January/February 2020)
- Designed to cover the core components expected in a Bill-to-Cash system
- Error buckets, reference data, bill production, invoice validation, dispute management, netting, collection, payment & finance
- Subcomponents required within each major area (e.g., bill production = frequency, format, data displayed, etc.)
Sent a Survey to our benefactors (March 2020)
- An opportunity for each benefactor to mark each subcomponent with a RAG status (Red, Amber, or Green)
- Red – No current capability. Amber – Item in development. Green – Available in core product
- An open opportunity for benefactors to highlight any other capability not in the core requirements document
Provided an Analysis (April 2020)
- 6 benefactor responses
- Most benefactors have majority of capabilities
- Some areas are more advanced/developed and demonstrations would clarify “operational ease of use” and process flow
- Identified that members want further detailed demos on dispute process (invoice validation, CDR analysis, etc.)
Asking our Benefactors to Demo (TBA)
- Handling a dispute – Demo of disputes that have volume, rate, and deal rate discrepancies (incl. access to CDR’s, price lists, deals)
- How system retrieves needed data in order to share with supplier (CDR extracts, original email with price list attached, original email with deal attached or signed contract)
- How system sends dispute details, explanations, and supporting files
- How system compares the two parties’ CDRs (e.g., Telia vs. BT records), and how deviations are highlighted
- How system can update existing disputes based on analysis evolution (e.g., internal process error, missing/incorrect contracts)
- How system executes rerating and other corrections in relation to dispute analysis
- How system sends a credit note (partial or full) based on dispute analysis