普华永道审计笔记.docx
- 文档编号:1719655
- 上传时间:2023-05-01
- 格式:DOCX
- 页数:21
- 大小:37.25KB
普华永道审计笔记.docx
《普华永道审计笔记.docx》由会员分享,可在线阅读,更多相关《普华永道审计笔记.docx(21页珍藏版)》请在冰点文库上搜索。
普华永道审计笔记
审计笔记
序言
毕业后来到普华,从事审计工作,如今已经五个年头了。
在这五年里,通过和同事们一起努力的工作,得到了一些感悟,也总结了一些我认为不错的工作方法,这里和大家分享,希望大家取其精华去其糟粕,为之后的工作带来帮助。
下面根据公司的level状况将我的体会分为A2、A1、SA3和SA2&1四个阶段阐述,并在最后附上了一些我认为对大家工作或许会有些帮助的附件,供大家参考。
第一章:
A2阶段
一.心态要好,要自信
作为新入职的A2,也许在项目上遇到了很多让自己很迷惑的问题,而这些问题,有时会被自己的A1或者senior认为是stupid的question。
这时一定不能气馁,觉得自己是不是真的很stupid,或者不适合干这行。
其实我可以负责任的告诉遇到这类困难的新同事,出现这样的情况是非常非常正常的。
记得我刚进公司的时候,做一个小项目,负责10个左右的balancesheet科目,当时什么也不懂,senior让我去问客户要银行对账单和余额调节表,我便原话转告了客户。
谁知道客户看了看我,问“你是要最后一个月的还是要全年的”。
我之前也没要过,哪儿懂这个啊,于是想了想,觉得要全年的肯定没错,于是就和客户说了。
谁知道她马上就说“全年的太多了给不了,你们去年也就要了最后一个月的啊”。
我这个没面子啊,心想弄了半天你知道啊,知道我是新来了就逗我玩儿。
还好我属于脸皮比较厚的那种,笑着把最后一个月的问客户要了。
事后我仔细想想,有些事情真的是这样,做过一遍以后就知道了,但第一次做就很容易搞不清楚状况,显得很stupid。
遇到这种情况的小朋友,一定不要有什么挫败感,甚至以后做事都畏首畏尾的,没有必要,一次做错了以后知道了就行了,而且接触的新东西越多,犯错的机会就越多,最后经验积累的也就越多,这绝对是一件好事。
还有一点,不要总觉得自己是rookie,你是一个在学校里是老大的大四毕业生。
二.Draftpaper
作为A2,我们接受的第一项任务也许就是把今年的workingpaper的架子搭好,那么该如何搭好架子以便我们fieldwork时会更efficient呢?
下面根据我的经验给大家几点建议。
1.尽量理解上一年经过review了的paper
“站在巨人的肩膀上我们会看得更远”,搭paper的架子也一样。
既然去年的workingpaper已经完成并得到审阅,在客户整体业务,项目的engagementpartner和manager的要求没有大的变化的情况下我们为什么不参考去年的工作呢?
因此,我们在搭今年workingpaper架子的时候就要先问SIC(SeniorInCharge)要一下去年database的授权,然后把去年各step里的底稿download到local,好好熟悉一下去年paper的整体结构和present的思路;
2.搭架子的时候“宁抄勿创”
有些新同事比较喜欢创新,觉得去年做的paper“不怎么样”,应该改改,甚至全部推倒重来。
于是便花了大量的时间去自我创新,但根据我接触到的实际情况,往往结果却是远远不如上一年的paper满足要求。
其实创新并没有错,关键是对于一个新入职的A2来说,经验不足,理解能力有限,很有可能把全年的经典不当回事,狂删一通后又不知道该怎么重新搭建。
这样的工作方式基本属于费力不讨好,应该坚决杜绝。
我这里建议的方法是先按去年的搭今年的架子,觉得那块儿自己理解不了或是需要改进,和自己的senior沟通一下,这样既有助于自己的理解,又能让senior觉得自己是在用心的做,而不是一味的照抄,而且还比较节省时间;
3.分析paper的结构
搭paper架子的过程其实也是了解审计方法和思路的过程。
一张比较好的paper,它的结构应该的非常清晰和完整的,一般包括几张sheet:
tailorprocedure的response(做大项目的时候一般会有个CTinstruction,我给小朋友的要求是必须对instruction中的内容每条都要写response,并且建hyperlink到后面的worksheet)、disclosure、lead、breakdown,以及一些retest或者vouching的worksheet。
Paper的完整性是搭架子是需要满足的首要条件,也是seniorreview时重点关注的部分;
4.Paper内部的linkage关系要明确
Paper中会有会有很多的数据,这些数据都是应该有来源的,因此我们可以通过建hyperlink的关系将这些数据的来源呈现出来。
一般来说,disclosure中的数据link到lead或者breakdown,lead中的数据应link到breakdown中,breakdown中的数据应link到客户提供的PBC中。
一些用于分析的worksheet中的数据比如tiein,retest中的数据一部分link到breakdown中,还有一部分可能会link到其他审计底稿。
Paper中linkage的建立我的建议是越多越好,能用linkage的绝不key数。
这样一方面不会造成lead和breakdown对不上的情况,另一方面将整个审计的脉络呈现的十分清楚,更重要的是,这样做也为seniorreview和第二年的update提供了便利。
三.对PwC的三种基本审计方法的理解
我们的审计过程实际上就是对我们出具的审计报告上的数据获得comfort的过程。
如何获得comfort?
SoC(SummaryofComfort)里给出了三种方法-Controltesting,Substantivetest(包括SubstantiveAnalyticalReview和TestofDetails),这里谈一下我的理解。
在我看来,这三种获得comfort的方法实际上是和企业的发展历程相一致的。
在企业成立的初期,业务比较简单,收入主要体现在单笔的合同和收款,成本主要体现在单笔的发票和付款。
在这种情况下对应的审计方法其实很好选择–主要靠抽凭,主要是Reperforming和Examination的过程。
看看绝大部分的合同是不是真实,相关经办人员有没有把他们家的洗衣费之类的也贴票报了。
这其实就是TestofDetails的基本思路,在不会费太大力气的情况下采用检查细节的方法取得财务数据的comfort。
这种方法简单、直接、有效,获得的comfort程度也是最大的;
随着企业的发展,规模不断扩大,以前是一个项目,现在是几个项目了,这种情况下审计师要是再扑到所有的细节里去抽凭就变得不efficient了(虽然还是那么effective),这时候我们可以用另一种方法,将公司的几个项目进行横向比较,或是一个项目按年份进行纵向比较来获取comfort。
比如说几个性质基本相同的项目,规模也基本相同,Revenue都大约是100元,其中大部分项目的Cost是60元,但有一个项目Cost是90元,这时候我们需要“不comfort”,觉得“不reasonable”,认为“itdoesn’tmakesense”,关注其中是否存在虚增成本的情况,是不是相关经办人员把他们家的洗衣费之类的也贴票报了;同样的,同一个项目前一年毛利是40元,今年业务上没有任何特殊情况发生但毛利变成了10元,这也需要咱们审计师抱着怀疑的态度进行关注,进行analytics。
以上所说的横行和纵向的比较方法就是SubstantiveAnalyticalReview的基本思路。
又过了几年,企业又发展了,不但业务种类扩大了还成立了很多个子公司,变成多种经营的集团公司了。
这种情况下由于集团内部各公司业务种类的不同,项目之间变得不可比了,因此之前所述的横向比较的方法就变得不是很effective了。
但这时候我们可以用第三种获得comfort的方法–Controltesting。
对于一个管理比较完善的集团公司,为了方便其自身的管理,一般都会制定一套SOP(StandardOperatingPrecedures),里面会分业务板块规定详细的操作流程,等同于各部门岗位的工作手册,公司大业务性质多不要紧,只要都按制定的操作流程去办,对于公司管理层来说,就将评价各部门岗位的业绩是否真实这一MissionImpossible变成了监督和考量各部门岗位员工是否按照SOP去做,而后者可以采用抽样的方法,这就使对集团公司这样的大公司的业绩考量变得可行和efficient了。
对于审计来说也一样,抽凭抽不过来,比较分析不可比,不要紧,咱们也沿用上面管理层用的方法。
公司SOP一般会涵盖业务的各个方面,我们则需要Scoping出对FinancialStatement影响较大的流程,获得对应的SOP进行Understanding,并进行Evaluation,如何判断SOP有效的话再选样本进行Validation,最后给出Conclusion,到底是能不能RelyonControl。
这其实就是Controltesting的基本思路。
四.对Materiality的理解
Materiality(重要性水平)是贯彻审计工作始终的一个非常需要的概念,它是尺度,也是成本。
那么该如何理解OM(OverallMateriality),以及相关的PM(PlanningMateriality)和SUD(SummaryofUnadjustedDifferences)呢?
这里我谈一下我的一些理解。
Materiality其实是一个容忍度的概念。
比如说路人甲实际口袋里有100元,路人乙问审计师这个人口袋里有多少钱,审计师调查后说有99元,后来实际证明是100元,差1元,路人乙一想,就差1元,算了,这种情况下审计师披露的数据的误差是报表使用人可以接受的。
但如果差10元,估计路人乙就不答应了,审计师披露的数据就会被认为误差让人难以接受,报表使用人就会跳起来。
这样看来,误差与真实值越小审计师的工作就越出色,但是另个问题就是越出色的工作就要做得越细致,越细致的工作意味着越多的成本,这就与审计efficient的精神有背离了。
那么我们就要寻找一个中间状态,比如说5元以下路人乙能接受,5元以上就不能,那么这个5元就是路人乙最大的错误容忍度,那我们就可以卡着这个差异去做工作,这样既能满足报表使用人的要求,又能节省审计师的成本,做到既effective又efficient。
这个5元的卡儿,就是Materiality(OM)的概念。
而对于审计师来说,要保持一定的谨慎性,最好不要卡的那么紧,给自己发现的错误打点儿富余,比如说20%吧,那么我们工作的时候就以4元作为我们可以接受的误差标准,这样即使事后证明我们还有少量的错误没有发现,如果差异不足1元的话,整体的误差也不会超过5元(OM)。
这个20%的富余,就是我们常说的Haircut的概念,而4元就是PM的概念。
又比如说,路人甲把他的钱分装在了10个口袋里,那么我们审计师审计的时候需要对每个口袋里的钱数都进行审计,如果这种情况下我们还以4元作为我们审查的标准的话,有可能一个口袋差1元,10个口袋加起来就是10元了,就大于OM了。
因此我们引入SUD的概念,用OM5元除以10,一份就是0.5元,用这个作为我们审计每个口袋里钱数的误差就显得比较合理了。
而这里的口袋类似于我们实际工作中的会计科目、或者会计科目的明细,每个科目或者明细的可容忍误差加起来才是我们对会计报表的整体误差OM。
有一点需要说明的是我们审计的基本原则是DoubleE(EffectiveandEfficient),因此大家在确定OM、PM、SUD的时候要在参照PwCAuditGuide的基础上充分考虑具体项目的实际情况(比如说报表使用人的态度,报表的使用用途等),不可只顾着照搬计算公式,尤其是对于那种比较多location的项目,各科目容忍度在单个entity上的分配可能会有一些灵活把握的因素,建议做一张Mapping的表把我们在单个entity、单个account上确定获得的comfort加总起来和OM进行比较,而不是光卡着SUD的概念埋头做。
五.两个重点审计步骤的介绍
1.银行询证函和余额调节表
A2在项目上做的第一项任务往往是发函证,这里和大家share一下我对发银行函证的理解。
向银行发放询证函是为了从银行这一十分可靠的第三方获得企业银行存款这一科目金额的comfort。
这一审计思路说白了就是企业在银行的存款有多少我们问问银行就知道了。
但是值得注意的是,作为审计师,我们签署的审计报告上的银行存款的金额是企业账面上的数,而并不直接是用银行中存款的数,而且在实务中我们经常会发现两者不等。
“企业账上的数为什么不等于银行账上的数?
两者的差额是什么?
既然不相等银行函证会不会失去了意义?
”
直观上来讲,企业存在银行的钱和银行里存着的企业的钱其实说的是一回事儿,因此似乎企业账上的数和银行账上的数应该一致。
但现实中,谁家没个意外情况什么的?
比如说2008年12月31日那天企业付款了,记了帐,但银行那天停电了,没有记上,这样就有差异了,企付银未付,谁的数对,当然是企业的,所以报告上的数应该按企业的数披露。
至于银行,他的数需要让他自己的审计师帮他调,咱们就不用管了;再比如2008年12月31日那天企业银行借款利息到期了银行自动扣息了,但企业相关会计人员当天刚好拉肚子了,没上班,出现差异了,银付企未付,谁的谁对,当然是银行的,所以报告上的数应该按银行的数披露,或者说按企业原有的数加上扣息的那笔付款之后的数披露。
从上面的例子我们可以看出,企业账上的数和银行账上的数有的时候是可以不一样的,对于差额企业要编制银行余额调节表,而针对表中的差额(调节项),不能放在哪里就不理睬了,要本着实事求是的原则进行分析,企业错了企业调,银行错了银行调(企业不用调,我们一般只管企业的调整)。
对银行余额调节项的调整与否,是我们审计师需要重点关注的事项,也是新同事最容易犯错误的地方。
对于银行函证上的数字应该是写客户账面的数据还是银行对账单上的数据这里我们讨论一下。
理论上来说,报告上披露的数据似乎离客户账面数要更近一些,试想如果银行确认了客户账面上的数据,那么我们报告上披露的银行存款数据该多有comfort。
但是遗憾的是,银行一般不会接受拿着企业的数到他那儿去函证,他手头只有他自己的帐,通过银行对账单来反映,所以我们就只能拿着银行对账单(A)上的数去做函证,然后审查上文中重点强调的银行余额调节表(B),最后采用A+B=C(企业账面数)的方式去verify我们报表中披露的银行存款的数。
值得注意的是,”C=A+B”,A和B的verify缺一不可。
2.盘点的思路
如果简单理解的话,盘点其实就是数东西,账上是10个,实际一数8个,少了两个,对不上了,我们就认为很可能有问题。
数东西的工作是盘点的核心,而对于审计师来说,我们更要关注的是整个盘点(以存货盘点为例)的一套逻辑。
首先盘点是企业自己的事,公司制定盘点计划,库管人员实施,财务和内审人员监督,外审人员(也就是我们审计师)只是在必要时(如出具年审报告时)监督并抽查符合,每次盘点结束了参与人员签字画押。
将上述事项说的再细致一点我们就可以感觉到盘点工作中需要关注的问题。
1.我们要获得公司制定盘点计划并审查其合理性,然后再对应的填写一下我们PwC要求的一些document;2.询问客户针对年审工作盘点的具体时间和各部门参与的人员;3.我们最终关注的是金额而非数量,因此我们需要首先从财务部获得盘点当日的资产负债表(一般为2008/12/31),锁定存货的余额,然后获得对应的单项存货的明细。
这一步非常重要,一定要保证明细(分仓库、分性质)的合计能和资产负债表中存货的余额能对上;4.存货金额的明细有了,我们还需要拿到单项存货的金额组成的list(金额=单位成本*数量,这个财务或者仓库一定是可以run出来的,我认为这个是盘点中最关键的一张list);5.到了这一步我们还是不能着急数数,由于”金额=单位成本*数量”,因此在数数之前我们还一定要关注一下单位成本这个概念,整体上看看合不合理,再抽上几个看看当时采购的发票。
这一点非常重要,而且往往被人忽略。
试想一下如何不去大体上verify一下单项存货的单位成本,客户之前如果贪污了几个存货,为了在实物盘点时不被审计师发现有差异,就先盘一下数量,然后用账上的金额除以数量倒挤一个数在单位成本了,这样不就蒙混过关了嘛;6.之前的五步都做完了,剩下的工作就是看着客户数数以及自己抽样去数数了,这个我就不多说了,照着PwCMethodology去弄就行了,另外就是前车之鉴:
不要看花眼、不要被存货砸到、不要掉进罐子里。
7.临走的时候带上客户的盘点计划、盘点报告(各部门签字)和复印的抽样样本。
8.对于盘点对不上的情况这里就不赘述了,基本思路和上文中提到的银行余额调节项的处理方法一致。
9.Rollback和Rollforward这里也不说了,照着PwCMethodology去弄就行。
六.与客户的交流
1.审计师的作用
审计师这个行业为什么会出现?
他是为谁服务的?
他的Value又在哪里?
有人说:
审计师是股东找来看住管理层的;
也有人说:
审计师是管理层找来忽悠股东的;
有人说:
审计师是小股民找来看住大股东的;
也有人说:
审计师是大股东找来忽悠小股民的;
有人说:
审计师是投资者找来审定被投资企业的;
也有人说:
审计师是被投资企业找来忽悠投资者的;
有人说:
审计师是公正的,崇尚真理的,是君子爱才取之有道的;
也有人说:
审计师也是个打工的。
2.推荐基本我读过的认为还不错的书
提到审计方面的书也许大家会想到CPA的教材,但我这里给大家推荐的是像我这样非会计专业毕业的同事入门用的,我觉得还行,基本思路就是先学会作一名会计,能和客户顺畅的沟通了,再来谈审计的事儿:
《如何制单、记账、报表、报税》、《注册会计师10日读》、《查账业务实战速成》、《如何合理避税》。
3.我对CPA学习及考试的一些想法
其实从某个方面来说,我在这个话题上没有太多的发言权,因为从某种意义上来讲,正是我在这点上的战略”错误”导致了我会计师职业生涯的结束。
记得刚进公司的时候,一位师兄和我说“工作是公司的,CPA证是自己的”。
当时我不是很认同,因为我觉得一个人的价值取决于他的贡献,而不是几张纸。
所以我当时对CPA的定位不是资格,而是一种能配合我创造价值的工具。
来普华的第一年,我一口气报了五门,力求让我这个非会计专业的同学能在最短的时间内了解审计对应的各个方面,结果可想而知,一门也没过;第二年还是如此,还是一门没过。
升了Senior了,我开始尝试去主攻会计、财管、税法这些工作中最核心的科目,知识掌握的还可以,题做不完,考试的效果还是不理想。
总的来说,我这种方法能使自己用最快的时间培养sense,分析问题比较全面、出现了问题知道到书的哪一页去查,和客户以及同事交流比较顺畅,但最致命的缺点就是做题时间少,考试过不了。
因此从现在的结果上看,我在CPA方面的经历有一部分是经验,大部分是教训,大家一定要取其精华取其糟粕,在做好工作的同时通过CPA的考试。
六.与上级领导(A1和Senior)的交流
1.所说的语言要到位
在我看来,一个合格的A2问A1的问题应该是“通过和客户的沟通和我的分析,这件事应该是XXXX的,该怎么处理?
”。
就是说要通过自己的了解gatherinformation,并能把故事完整的说出来;
相比之下,一个合格的A1问Senior的问题应该是“我们了解到,这件事应该是XXXX的,处理的方法我觉得有几种几种,应该用哪一种?
”。
也就是说不光要把事儿说情况,还有给出建议,具体选择哪儿不清楚不要紧,但要把可能的选项都列出来;
对于一个合格的Senior问Manager的问题应该是“我们了解到,这件事应该是XXXX的,处理的方法有几种几种,我觉得该用XXX种,对不对?
”一个Senior尤其是SIC光是列outstanding是不够的,最重要的是要有自己的判断,而有了结论,最好也不要自作主张,一定要和Manager交流,让他最终拍板,这样才能保证issue信息传递的efficient和effective。
当然,如果一个A2能问出A1甚至是Senior的问题他就HighPerform了,这也是我们应该在team里鼓励的。
2.具备基本的sense、knowledge和technique
这个我推荐大家看一本叫《审计一家言》的书,作为auditwork的入门很不错。
七.为成为A1做准备
如何在将来胜任A1的工作,最简单的方法是在A2的时候就去involve一些本该由A1做的工作。
我觉得基本上几个方面:
Accounts-这个好办,A1的科目自己抢着做,不明白的让A1给些Coach;Review-A1的一项重要工作就是reviewA2的工作,所以对于A2来说,在交出东西之前做好selfreview就是像A1过渡的重要一步;Report-A1一般是report给Senior的,刚来的A2有时候会比较害怕和highlevel的同事交流,我的建议是A2可以选一些生活中的话题和Senior交流找找彼此之间的感觉,克服紧张感。
总之,A2主动去帮忙干一些A1的活儿在team里一般是很受欢迎的,起码我就很乐于这种风气,这种风气不但要靠SIC来创造和鼓励,A2自身的态度才是最重要的,最具有决定性的。
第二章:
A1阶段
一.Database
1.建立项目Database时需要用到的几个Database
FFMV2.12f(授权)、CN/HKAuditEngagementConfirmation(independenceconfirmation)、CN/HKTemplateManager(Bankconfirmation、PreliminaryAnalyticalReview、FinalAnalyticalReview之类的重要底稿的最新模板)、TeamFindV2.12(查询项目的基本信息和人员)、CN/HKTaxRiskAssessment(taxreview)、AssuranceRiskManagement(ARM)/CN/HKPwCAuditMethodology&Tools/ChinaTechnicalResources(这三个database我们做工时technical方面需要参考)
2.对Database的理解
这里以最简单的VSE为例谈一下我对咱们Database整体结构和思路的理解。
在我看来,Database有两条主线,一条明线是我们工作的流程,一条暗线是准则的满足。
先说第一条线-工作的流程,这个是比较直观的:
首先我们先阐明选择此类database的原因(BackgroundtotheMasterData),然后开始做审计计划(Planning),包括“客户承接与续约,独立性”的问题,没问题的话签订“审计业务约定书”,“初始计划工作及客户联络”,从大的方面看看公司的管理怎么样,有没有什么大的风险-“验证内部控制要素”,然后制定“具体审计策略和具体审计计划”,计划做好了“签字合伙人及签字经理签署”。
下来开展具体的现场审计工作,让SPA(或者我们自己)做一下公司的ITGC测试,保证依赖的电算化系统数据是没问题的,然后做SOC(SummaryofComfort,这阶段的工作请见第一章第三点中提到的获得Comfort的三种方法-Controltesting,Substantivetest(包括SubstantiveAnalyticalReview和TestofDetails)),SOC中原则上来讲就写明了我们计划执行的具体审计步骤和获得的Comfort。
计划好了下来就是实施,首先找出keyrisk编写A
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 普华永道 审计 笔记
![提示](https://static.bingdoc.com/images/bang_tan.gif)