應付帳款流程圖(完整應付周期)

應付帳款全周期流程圖:發票在各渠道接收、供應商主檔資料核實、重複與採購訂單核對、異常隊列、付款批次與期末應計。

使用此範本

甚麼是應付帳款流程圖(完整應付周期)流程

應付帳款是一項職能,而不是一列等候處理的發票。它負責的範圍,是由一份供應商單據在某個渠道到達,到期末機構能夠準確講出自己欠了誰、欠了多少的這一整段。這個跨度包含許多在「單張發票流程圖」上永遠看不到的工作:令供應商主檔資料保持可信,把異常隊列當作一份受管理的積壓來營運,編製並審批付款建議清單,在銀行放款,把供應商認為你們欠的金額與你們總帳上的金額對上,以及為尚未處理的發票作應計入帳。

本範本刻意畫得比單張發票闊,也刻意畫得比採購窄。它不是一張發票審批圖:單張發票經過輸入、重複檢查、三方比對、入帳科目分配和按金額分級審批的路徑,在這裡被壓縮成一個比對決策和一個預算負責人決策——發票審批流程範本會詳細涵蓋那條路徑。它也不是採購流程:請購、尋源、採購訂單發出和收貨都發生在這張圖開始之前,採購申請和採購訂單範本會在那裡接手。本頁的深度落在審批之後——付款批次和期末結帳,正是應付帳款不再只是一個處理團隊、而開始成為資金與監控職能的地方。

大多數應付職能會在五個可以預見的地方出事,而這五個地方在這張圖上都看得見。發票由沒有人接入接收環節的渠道進來,於是重複檢查根本看不到它們。供應商的銀行資料單憑一封電郵就被改掉。異常被丟進一個沒有負責人、也沒有帳齡的隊列,悄悄變成下個月的未入帳負債。付款建議清單是按誰催得最緊來編的,而不是按到期日和付款條件。而期末應計漏掉了仍然留在異常隊列裡的發票。這張圖橫跨五條泳道(供應商、應付帳款文員、預算負責人、財務主管和財資部)和六個階段,令上述每一個失效點都有一個具名的負責人,而不是籠統地歸給「財務」。

本流程圖涵蓋的內容

本範本包含

  • 涵蓋整個應付職能而不只是一張發票的五條泳道:供應商、應付帳款文員、預算負責人、財務主管和財資部;橫跨六個階段:接收、核對、入帳科目分配與審批、異常隊列、付款批次和期末結帳。
  • 多渠道接收:在任何檢查開始之前,把所有到達路徑匯入同一個隊列,隨後輸入應付系統,這樣任何渠道都無法繞過後面的控制。
  • 把供應商主檔資料當作一個控制步驟:「供應商與銀行資料是否已核實?」決策,附有一條「資料有變」分支通往「以回撥確認銀行資料變更」,之後發票才可以繼續往下走。
  • 把重複檢查放在所有比對和入帳科目分配工作之前,並設有「重複發票已攔截並記錄」的出口,令懷疑重複的發票停在那裡,而不是被悄悄刪掉。
  • 「是否引用了採購訂單?」這個分岔:有訂單的發票走「訂單、收貨與發票是否一致?」,無訂單的發票走預算負責人的「無訂單發票是否批准?」決策;差異分支和爭議分支都匯入同一個異常隊列,在那裡登記疑問、由供應商開出貸項通知單或更正發票,再由「疑問是否已解決?」把發票送回入帳,或者終止於「發票已拒收並退回」。
  • 單張發票的流程圖永遠去不到的付款周期和期末結帳:「編製付款建議清單」、財務主管的「付款批次是否已批准?」決策及其退回建議清單的「修改」迴路、財資部在銀行的執行、應付帳款文員發出的匯款通知、供應商對帳單核對,以及「為未處理發票作應計並結帳」。

何時使用本範本

  • 你們要編寫或更新一份必須由頭到尾涵蓋整個職能的應付帳款政策或 SOP——包括付款批次和期末結帳,而不只是發票審批。
  • 你們要建立或重組共用服務中心,應付帳款文員交給財務主管、再交給財資部的交接必須寫明,而不是靠默契。
  • 你們要準備一次針對付款周期的審計或內部監控穿行測試,問題在於誰入帳、誰批准付款批次、誰在銀行放款。
  • 在發生一次重複付款、一次錯付,或一次試圖變更銀行資料的事件之後,你們要檢視控制措施,需要說明控制點在哪裡、由誰執行。
  • 你們要為應付自動化、電子發票或 ERP 遷移界定範圍,接收渠道、異常原因代碼和付款日程必須在設定之前先議定。

運作方式

  1. 列出發票可能進來的每一個渠道

    把它們全部寫下來:共用郵箱、供應商入門網站、EDI、實體郵件,以及直接寄給某位預算負責人或某個廠區的發票。任何一條沒有接入接收步驟的路徑,同時也略過了重複檢查,所以要麼把它接上,要麼把它關掉。記下哪些渠道是自動化的、哪些需要人手處理——積壓就是在那裡形成的。

  2. 把供應商主檔資料規則訂下來

    寫明誰可以建立或修改供應商紀錄,以及誰核實銀行資料變更、如何核實。要用主檔資料中原有的號碼致電供應商,絕不用發票或變更申請上的號碼;輸入變更的人和批准變更的人必須分開。記錄由誰核實、何時核實、核對的是哪位聯絡人。

  3. 訂下比對容差和無訂單發票的路徑

    把你們真實的價格和數量容差寫在「訂單、收貨與發票是否一致?」這個決策上,並寫明哪些開支必須有採購訂單。然後決定:一張本應有採購訂單卻沒有的發票要怎樣處理,令它成為一個有紀錄的例外,而不是預算負責人悄悄批掉的東西。

  4. 給異常隊列配上原因代碼和帳齡

    把單一的疑問步驟換成你們自己的原因代碼——例如價格差異、無收貨紀錄、無採購訂單、交付有爭議,或供應商資料缺失。為每個代碼指定負責人,並按日數議定催辦和升級的時點。一個沒有負責人、沒有帳齡的隊列,就是發票被遺忘的地方,也是期末意外的來源。

  5. 界定付款日程和付款批次的審批人

    訂下多久跑一次付款批次、建議清單如何篩選(到期日、付款條件、即將失效的現金折扣),以及哪些不納入。然後寫明誰審批建議清單、誰在銀行放款,並令這兩個角色與編製清單的人、以及任何可以修改供應商銀行資料的人分開。

  6. 議定期末要為甚麼作應計

    決定財務主管為甚麼作應計:已收到但尚未收到發票的貨品和服務,加上仍在異常隊列中未結的全部項目。議定這份清單由誰提供、在結帳時間表的哪個節點產出,以及應計在下期如何撥回,令隊列反映在帳目上,而不是藏在帳目背後。

  7. 把這張圖走一遍,並只保留一個已批准的版本

    和一位應付帳款文員、一位預算負責人、財務主管以及財資部一起檢視這張圖,把它改成他們實際在做的事,而不是政策上寫的事。然後把議定的版本納入版本控制,並從應付帳款政策連結過去,令大家依據現行的圖工作,而不是依據舊培訓教材裡的一張截圖。

常見問題

應付帳款流程包含哪些步驟?

一個完整的周期是:由任何一個接收渠道收到發票並輸入應付系統;確認供應商存在於已批准的主檔資料中,並核實任何新增或變更的銀行資料;檢查是否重複;判斷是否引用了採購訂單;有訂單的發票與採購訂單和收貨紀錄比對,無訂單的發票交預算負責人做入帳科目分配和審批;把差異和爭議轉入異常隊列,與供應商解決;已批准的發票入總帳;編製付款建議清單;取得付款批次的批准;執行付款並發出匯款通知;核對供應商對帳單;以及為期末尚未處理的發票作應計。

應付帳款流程和發票審批有甚麼分別?

發票審批是應付帳款裡的一個環節。它涵蓋單份單據由收到到具備付款條件的過程:輸入、重複檢查、比對或入帳科目分配,以及由與金額相稱的合適人員審批。應付帳款流程則是圍繞這個環節的整個職能。它還包括令供應商主檔資料保持可信、把異常隊列當作附有負責人和帳齡的積壓來管理、把已批准的發票匯總成付款建議清單、取得付款批次的批准並執行、核對供應商對帳單,以及為尚未處理的部分作應計。如果你們只需要詳細的審批路徑,就用發票審批流程圖;如果你們需要說明整個職能如何運作、資金實際在哪裡流出,就用這一張。

應付帳款應該怎樣處理供應商銀行資料變更?

把它當作一個控制步驟,而不是一次事務性更新。核實變更申請時,要用主檔資料中原有的號碼致電供應商,絕不用申請裡給出的號碼,而且要找已知的聯絡人,而不是發電郵的那個人。輸入變更的人和批准變更的人必須分開;記錄由誰核實、核對的是哪位聯絡人;在變更確認之前,暫停對該供應商的付款。要求改付款帳戶是一種反覆出現的詐騙手法,它通常表現為一封看似可信的電郵,來自真實供應商的地址,或與之極為相似的地址——正因如此,核實必須在申請進來的那個渠道以外進行。

付款批次應該由誰審批?

由編製它的人以外的人審批,也要由可以修改供應商銀行資料的人以外的人審批。在大多數機構中,應付帳款文員編製付款建議清單,財務主管或財務總監依據授權審批表批准,財資部在銀行放款——通常還要有第二位銀行授權人做雙重監控。審批人需要看到按銀行帳戶和貨幣匯總的金額、被剔除的項目,以及任何不尋常的情況,例如新供應商或首次付款,而不只是一個付款宗數。令這三個角色互相分開,正是審計人員在穿行付款周期時會查看的職責分隔。

應付帳款為甚麼要在月結時為未處理的發票作應計?

因為權責發生制要在貨品或服務被接收的期間確認開支,而不是在發票剛好被處理的期間。結帳時總有兩類項目否則會被漏掉:已收到但尚未收到發票的部分,以及已經在公司之內、但仍留在異常隊列或等候審批的發票。財務主管為兩者都作應計,令本期的成本和負債完整,並在發票入帳時把應計撥回。這也是異常隊列的意義超出應付職能的原因:一個沒有負責人、沒有帳齡的隊列,會令應計變成一個估算,而不是一份清單。

使用此範本

屬於以下套裝

流程圖範本的更多內容

Browse all 財務與會計流程範本