在准實時計費和實時計費之間，實際還存在一種折中的解決方案，那就是分話單計費，所謂分話單計費，就是產生話單的交換機，對可能會產生高額費用的話單進行分割，比如用戶在使用語音業務，在打了30分鍾電話后，交換機先出一張話單出來給計費，計費完成后判斷是否余額足夠，如果不足就發出停機，網絡側在收到停機單后，中止用戶通信（這一點存有疑問，問過一些熟悉的人士，有些說可以中止，有些說不能中止，期待解答），避免造成高額的欠費。
然而對於計費，如果不對分話單進行單獨處理，可能會造成計費的錯誤。比如一條2分鍾的話單，被切割成61秒和59秒，就會計算為3分鍾（不足一分鍾按一分鍾計算，前面算2分，后面算1分），這樣用戶肯定會投訴。所以，分話單業務需要在計費時有單獨的處理步驟。一般的做法是，在計費時，如果是分話單，計費完成后，做一個記錄，同次通信的下一條話單過來后，再將這條記錄合並，並根據合並后的話單的費用，減去計算上次話單的費用，得到這一條話單的費用。
這里面存在的最大問題是給用戶查詢的問題。用戶查詢時，需要查詢到的是一條話單，后面交給經營分析和統計的數據，也需要是一條話單。計費最終輸出的，應該是一條話單。所以，這條話單在沒有完成全部計費前，不能交給入庫和合帳處理。如果不交給合帳處理，就參考不到前面分話單的費用做信控處理。就失去了分話單的本意。所以，要么是查詢模塊做出修改，查詢時考慮分話單的邏輯，要么就是信控模塊做出修改，信控時參考分話單”預留”的費用。要說根本解決問題，自然是信控模塊修改好些。
有一個終極的解決方案，分話單的流程與在線計費的流程非常相似。分話單的首單，更新單，尾單可以映射為在線計費的初始包，更新包和結束包。將分話單的業務轉成消息處理就可以解決上面的所有問題。它是怎么解決的呢？分話單轉消息用OCS的流程，余額就會被預留，自然就解決了這個問題。
話單計費還是消息計費，從表面上看是文件接口還是消息接口的問題，實際上，文件接口或者消息接口，僅僅是協議層面，定義好了相關的文件格式或者消息格式，流程上不會因此產生差異。真正產生差異的，是目前文件計費(OFCS)和消息計費(OCS)在余額流程上的差別。長期以來，由於系統的慣性，我們把系統分為了計費和帳務兩塊，計費管計算費用，余額管扣減費用。所以OFCS在計費時，並沒有把余額真正的扣除，而只是做了累加，信控的時候參考”可用余額”和累計的費用的大小，而OCS計費時，余額會被扣除，信控的時候，僅僅參考余額。文件計費轉消息計費，流程最大的不同就是，余額是不是被扣除（或者預扣），信控流程是參考累積費用+余額還是僅參考余額。文件消息轉到消息計費，拋開效率的問題不談，實際上僅僅是兩者流程的統一。
當然，還有個大殺器，語音業務按秒計費，數據業務按字節計費，大家以為然否？