简介：本资源是一份面向Oracle EBS R12财务实施顾问、财务关键用户及运维人员的月结专题培训演示文稿，围绕月结概述、子模块与总账关系、关帐顺序展开，并重点讲解应付、采购、库存、应收、资产、PAC及总账等模块的详细结帐流程与对帐方法。内容涵盖发票与付款处理检查、会计科目创建、凭证传送与过账、供应商余额核对、期间关闭、库存盘点与成本更新等实务操作，并结合具体报表与SQL对账思路，适合用于月结制度的系统学习、上线初期方案梳理及内部培训参考。资源包共1个文件，为pptx演示文稿，压缩包大小2.9MB，内容以结构化目录呈现，知识密度较高。目前已有60人学习下载，适合对Oracle EBS财务模块月结与对账机制有一定了解、希望快速掌握各模块关账顺序及关键控制点的读者。
1. OracleEBS R12月结到底在结什么：一次只讲清楚一件事
每个月底财务部催着关账，OracleEBS R12系统里却还有几十张未过账的凭证没处理，这种事情在实施和运维现场一点也不少见。所谓月结，不是点一个“Close Period”按钮就结束，而是一个跨模块的闭合流程：把GL总账、AP应付、AR应收、FA固定资产、Inventory库存这几个模块本期间的所有业务全部确认、过账、对平，然后把会计期推进到下一期。整个过程如果你只操作GL，会发现怎么都对不上数；如果你不管子模块，GL这边关了账，前面AP还在往里传凭证，后面AR还有收款没确认——这种状态就是大家常说的“月结算关了个寂寞”。
这篇文章把OracleEBS R12财务月结按“前置检查 → 子模块关账 → GL关账 → 验证对账”拆开讲，适合两类人看：一类是刚刚接手EBS财务模块运维的IT人员，需要一套可以直接照着做的流程；另一类是做实施项目的功能顾问，需要知道月结时哪些参数会影响结果、哪些操作顺序不能反。内容以R12为基础，重点讲GL、AP、AR、FA四个模块的配合关系，不涉及采购库存的复杂成本结算，那些属于另一个量级的课题。最后会给出验证月结是否闭环的SQL，以及我最常踩的几个坑。
2. 月结前夜：会计期与数据完备性检查
2.1 会计期先打开，子模块才能进单
先确认一件最基础的事：GL的会计期打开了吗？子模块的会计期打开了吗？两个不是一回事，但经常有人忽略。在OracleEBS R12里，GL打开会计期之后，AP和AR才能把该期间的事务处理过账到GL；反过来，如果GL还没打开该期间，你在AP做Invoice Validation时会报“Period not open”，根本走不下去。
常见做法是每个月初先打开系统里所有相关模块的下一个会计期，但月结的时候我们要确保的是：本期间已经打开了，而且没有其他人员在同一个期间里乱做业务。上线初期发生过这种事故：财务在月末跑月结，采购同事在AP里录入了一张发票，结果GL关账后，这张发票验证通过并过账，直接进了已经关闭的期间，导致Trial Balance对不上，最后只能用Reopen Period把期间重新打开。所以我自己做月结，第一件事永远是查会计期状态，而不是直接跑请求。
-- 查看GL与子模块会计期状态 SELECT gl.name AS ledger_name, glp.period_name AS period_name, glp.period_year AS fiscal_year, glp.period_num AS period_number, glp.quarter_num AS quarter_number, glp.closing_status AS gl_close_status, glp.period_type AS period_type, glp.period_status AS period_status FROM gl_periods glp, gl_ledgers gl WHERE glp.ledger_id = gl.ledger_id AND glp.period_name LIKE '%-18' AND glp.period_type = 'A' ORDER BY glp.period_year, glp.period_num;这段SQL查询总账的会计期状态，period_status字段是月结的关键，它会显示O（Open）、F（Future Entry）、C（Closed）、P（Permanently Closed）等状态。在月结前，period_status必须是O或者F，一旦变成C就说明已经有人动过关账动作。代码里period_name LIKE '%-18'是限定会计期年份，实际使用时改成你对应的年份和期间关键字。
这里有一个很重要的细节：R12中GL会计期是独立的，而AP、AR、FA、Inventory的会计期维护在各自模块里。你可以在子模块打开多个期间，甚至让子模块的当前期间和GL不一致，但月结时所有模块的期间必须对齐到同一个期间。我一般建议在月结开始前跑一遍SQL把五个模块的打开期间列出来，人工对一遍，防止某个子模块的期间还停留在上一期。
2.2 未过账、未验证、未转账：三类脏数据的SQL体检
会计期打开之后，下一步是查“脏数据”。月结最怕的不是账做错了——做错了可以调，最怕的是账没做完。系统里还有未验证的发票、未过账的日记帐、未创建会计分录取证的收款，这些都会在月结时变成拦路虎。
第一类要查的是GL里未过账的日记帐。很多人以为Post Journals是一个可选步骤，实际上R12的GL月结要求所有本期日记帐完成Post，否则Trial Balance不平。出现过一种情况：调拨公司间往来的时候，日记帐保存了但还没Post，结果月结后子公司报表里应收账款对不上，查了半天发现是那笔调整没有过账。
-- 查询GL中未过账的日记帐 SELECT jh.je_batch_name, jh.je_header_name AS journal_name, jh.je_category, jh.je_source, jh.running_total_dr AS total_dr, jh.running_total_cr AS total_cr, jh.status AS journal_status, jh.posting_status AS posting_status, jh.ledger_id FROM gl_je_headers jh WHERE jh.ledger_id = 2025 -- 换成你的ledger_id AND jh.period_name = 'DEC-18' -- 换成你要关闭的期间 AND jh.posting_status <> 'P' ORDER BY jh.je_batch_name;posting_status字段有三个常见值：P表示已过账，U表示未过账，F表示过账失败。月结前查出所有不带P的记录，先解决掉。命中的记录里如果状态是F，说明过账过程中出现数据库错误，最常见的处理办法是进入日记帐界面重新点了Post。如果还是失败，就要去GL_INTERFACE表查是否有数据没进入GL_JE_HEADERS。
第二类要查的是AP的未验证发票。AP里一张发票只有从Pending变成Validated，才会生成会计分录取证。没有验证的发票不会出现在总账里，但它会让你在Accrue Uninvoiced Receipts之后怀疑自己的应计费用算少了。我见过一次翻车现场：财务人员以为所有发票都验证过了，跑完Accrue Expense，结果采购部在月末最后一天录入了一批发票但没人做Validation，导致未开票收货应计费用少计了十几万。
-- 查询AP中未验证发票 SELECT ai.invoice_num, ai.invoice_date, ai.invoice_amount, aps.vendor_name, ai.invoice_type_lookup_code, ai.validation_date, ai.amount_remaining FROM ap_invoices_all ai, ap_suppliers aps WHERE ai.vendor_id = aps.vendor_id AND ai.validation_date IS NULL AND ai.invoice_date <= :p_close_date -- 月结截止日期 AND ai.cancelled_date IS NULL ORDER BY ai.invoice_date;这段SQL核心是validation_date IS NULL，它是判断发票是否完成验证的唯一可靠字段。如果一张发票创建了但没验证，validation_date就是空的。注意不要用invoice_amount是否为0来判断，有些冲销发票金额为0但也是需要验证后才能在系统里留存。查出来后，能验证的就验证，不能验证的确认是否需要删除。
第三类是AR里未确认的收款。AR的收款要经过Create Accounting生成分录并且成功转移至GL，才会体现在总账。R12里利用SLA（Subledger Accounting）架构，AR的会计分录取证和转移是两步独立的操作：先Create Accounting，再Transfer to GL。如果业务量大，转移过程可能半途失败，导致GL有接口数据但没有真正过账。查询AR接口表是一种办法，但更直接的是查AR的Receipt状态。
-- 查询AR中未确认是否创建会计分录取证的收款 SELECT r.receipt_number, r.receipt_date, r.amount, r.status AS receipt_status, r.cash_receipt_id, r.attribute1 FROM ar_cash_receipts_all r WHERE r.status IN ('CONFIRMED', 'UNCONFIRMED', 'REVERSED') AND r.receipt_date <= :p_close_date AND r.org_id = :p_org_id -- 指定OU ORDER BY r.receipt_date;2.3 预算控制与外币：不影响过账但影响余额
很多项目上了预算控制，月结的时候预算状态会直接影响GL期间的状态。如果启用了GL Budgetary Control且当月预算还没有做调整为Final，可能出现期间无法关闭的现象。这类问题没有通用的SQL，因为预算控制表结构因版本和配置而异。我的建议是：月结前一周就把预算调整做完，不要在关账当天做预算。
外币这块则是另一条线。如果账套启用了多币种，月结时要做Currency Revaluation（外币重估），这是GL内部的步骤，不涉及子模块。重估不是简单的汇率折算，而是把以外币计量的科目余额按期末汇率调整为本位币，产生的汇兑损益进入指定的重估科目。这个动作必须在所有子模块传完数据之后再做，否则你重估出来的数字会漏掉之后进来的凭证。所以流程上它必然排在GL Post之后、Period Close之前。后面单独开一节讲。
3. 子模块月结顺序：AP、AR、FA谁先谁后
3.1 AP月结：Accrue Expense与Payables Close
AP模块月结的第一步不是跑请求，而是确认所有本期间的发票都已经完成Validation。接下来是处理未开票收货（Uninvoiced Receipts）。这个步骤的官方名称是Accrue Expense，但实际上它处理的是“已经收货、还没收到发票”的金额，需要按采购订单的接收记录计算应计费用，生成AP分录。很多项目这个步骤不做，因为他们的业务模式是先票后货，或者发票处理及时；但对于月末到货集中、发票滞后的企业，这个动作必须有，否则月结后的应付账款余额会少一块。
-- 检查是否存在未匹配的PO接收记录 SELECT pih.po_number, prh.receipt_num, rsl.quantity_received, rsl.quantity_accepted, rsl.quantity_billed, (rsl.quantity_accepted - NVL(rsl.quantity_billed, 0)) AS to_accrue_qty FROM rcv_shipment_headers rsh, rcv_shipment_lines rsl, po_headers_all pih, po_lines_all pla, rcv_receiving_rules rrr WHERE rsh.shipment_header_id = rsl.shipment_header_id AND rsl.po_header_id = pih.po_header_id AND rsl.po_line_id = pla.po_line_id AND rrr.receiving_rule_id = rsl.receiving_rule_id AND rrr.name = 'Standard' AND rsl.quantity_accepted - NVL(rsl.quantity_billed, 0) > 0;这段SQL的核心就是计算数量差异：quantity_accepted是已经接收的数量，quantity_billed是已经匹配到发票的数量，两者相减大于0说明还有货已经收了但发票还没到。跑完这个查询，你就能判断该不该做Accrue Expense。
Accrue Expense的操作路径是：AP Responsibility → Journals Entry → Subledger Accounting → Accrue Expense。请求跑完之后，要去核对生成的会计分录借了费用科目、贷了应计负债科目，这两个科目在AP选项中配置，常见问题是对应会计科目未建立账户组合，导致请求报错或分录跳行生成。
AP模块的关账动作是Payables Close和Payables Close-Close。前者是结束当前期间的过账权限，后者是彻底关闭期间的AP事务处理。我一般建议月结当天只做Payables Close，等GL整套流程走完确认无误，第二天或者隔天再做Payables Close-Close。原因很现实：如果Accrue Expense之后发现漏掉了某些应收的贷项通知单，只要还没做Close-Close，还可以回退；一旦Close-Close，就只能做下期的调整分录。
3.2 AR月结：Revenue Recognition与Receipt Reconciliation
AR月结的第一步是确认所有发票（Invoice）和贷项通知单（Credit Memo）完成了处理并创建了会计分录取证。R12中Create Accounting跑完之后，数据会进入GL_INTERFACE，然后由Transfer to GL这个请求把接口数据传进GL。这两个动作很多人当成一个步骤，实际上是两个独立请求，经常有人跑完第一个没跑第二个，结果GL里查不到AR的数据。
# 检查AR会计分录取证是否成功：Transfer to GL之后，GL接口与GL日记帐应该匹配 SELECT gjh.je_header_name, gjh.je_source, gjh.je_category, gjh.running_total_dr, gjh.running_total_cr, gjh.period_name FROM gl_je_headers gjh WHERE gjh.je_source = 'AR' AND gjh.period_name = :p_period_name AND gjh.posting_status = 'P' ORDER BY gjh.je_header_name;这段SQL查的是AR来源的已过账日记帐。如果查不到记录，说明要么Create Accounting没跑，要么转移失败。这时候不要重新跑AR请求，先把失败原因找出来：打开GL_INTERFACE表看status字段，如果是E说明接口数据有错误，查看error_message列会告诉你具体原因，通常是科目组合失效或账户段值被禁用。
AR月结另一个高发问题叫Receipt Reconciliation。它是把银行的收款记录和AR的应收发票进行匹配。R12里提供了AR Receipt Reconciliation和Quick Reconciliation两种工具。简单说，如果一笔收款没有匹配到任何发票，它就会挂在Unapplied状态，资金已经进账但应收账款的余额没有减少。月结时如果不对这一块做梳理，后续对账会很痛苦。
-- 查询AR中处于Unapplied状态的收款 SELECT r.receipt_number, r.receipt_date, r.amount, r.status FROM ar_cash_receipts_all r WHERE r.status = 'UNIDENTIFIED' -- 或 'UNAPP'，取决于版本 AND r.receipt_date <= :p_close_date AND r.org_id = :p_org_id ORDER BY r.receipt_date;收到这种结果，处理方式是确认该笔收款对应的发票，做Apply操作。如果实在无法匹配，至少调整到Suspense科目并记录原因，不要让它一直挂在Unapplied状态。月结前的AR对账要确认：所有已确认收款都已经Apply to Invoice，所有Unapplied已经处理或说明用途。
AR模块的关账动作是Receivables Close和Receivables Close-Close。和AP一样，也建议先做Close，确认GL对账无误后再做Close-Close。如果项目采用统一管理，AR和AP的Close-Close可以在同一天做，但顺序上AP先行。
3.3 FA月结：折旧跑完不等于关账完成
FA模块是所有子模块里最容易被人遗忘的。因为固定资产的业务量小，平时几乎没人操作它，但月结要是漏了折旧，麻烦非常大：折旧没跑，GL里固定资产的累计折旧余额就不动，资产负债表的数字就会和上个月一模一样。这种情况发生过不止一次，财务拿着一张上月和本月完全相同的固定资产报表来找我，问我是不是系统坏了，结果一看FA的折旧请求根本没有运行。
FA月结的操作顺序：先运行Depreciation Run（折旧），再运行Create Accounting（创建分录取证），最后运行Transfer to GL（转移到总账）。这个顺序不能错，折旧没跑完就没有分录取证可创建；Create Accounting没跑完，Transfer就没有数据可转。
-- 查询FA折旧运行状态 SELECT book.book_name, depr.request_id, depr.period_name, depr.run_status, depr.set_of_books_id, depr.accounting_status FROM fa_deprn_periods depr, fa_book_controls book WHERE depr.book_type_id = book.book_type_id AND depr.period_name = :p_period_name ORDER BY depr.request_id DESC;run_status字段显示折旧请求是否完成，常见值是C（Completed）和R（Running）。如果状态长期停留在R，说明并发管理器有异常，要去查并发请求日志；如果状态是C但accounting_status不是C，说明折旧已经计算了，但还没生成分录取证。这两个状态要同时是完成状态才算FA这一环结束。
FA有一个特殊参数：Depreciation Run的Run类型分为R（Regular）、B（Bonus）、S（Supplemental）。普通月结只跑Regular即可，但如果项目当初启用了Bonus Reserve（奖金准备）规则，还要跑一次Bonus折旧。这个参数很多人不知道，我见过一家企业月结后固定资产原值和累计折旧都正常，但资产净值多出一小块，查了三天发现是Bonus折旧从未跑过。
FA的Create Accounting请求还有个细节：它可以选择Post to GL的选项。如果你在FA里勾选了自动过账，分录取证会直接送到GL；如果没勾选，你需要在GL里对FA来源的日记帐手动Post。我建议所有FA产生的分录取证统一在GL月结时手动Post，这样便于统一控制过账节奏。
4. GL月结核心操作：从Post到Permanently Close
4.1 Post Journals：欠账不消，余额不平
所有子模块的数据都转移到位之后，GL侧的第一个动作是Post Journals。这是最基础但也是最容易被忽略的一步。原因在于，EBS的GL里，一张Journal即使被批准，只要没Post，它就不会参与账户余额的计算，Trial Balance也不会包含它。月结时发现余额不平，第一反应应该是查未过账日记帐，而不是急着去调账。
Post Journals的操作路径：GL Responsibility → Journals → Post。界面上会列出所有未过账的日记帐，可以全选然后点击Post。如果数据量大，建议使用Post Journals并发请求，这样有日志可查。过账失败时，去并发请求的日志文件里找SQLCA错误信息，最常见的失败原因是数据库锁或接口表死锁。R12里偶发过由于GL_JE_LINES表索引异常导致Post请求失败的情况，这类问题需要DBA介入，但作为功能顾问，你至少能从报错信息判断是应用层还是数据库层的问题。
Post完成的标准不是“请求成功了”，而是“所有来源的数据都过账了”。你可以用下面这个SQL检查各模块来源的过账状态。
-- 检查GL中所有模块来源日记帐过账状态 SELECT je_source, je_category, COUNT(*) AS header_count FROM gl_je_headers WHERE period_name = :p_period_name GROUP BY je_source, je_category ORDER BY je_source, je_category;这段SQL把当前期间的日记帐按来源分组统计。JE_SOURCE字段会显示AP、AR、FA、GL、INV等来源。理想情况下每个来源都有记录，并且数量符合预期。如果某个模块来源的记录数为0，说明该模块的数据根本没进入GL，回头查子模块的Transfer to GL请求。我当时做月结的习惯是把各来源的日记帐数量记录下来做成一张表，每月对比数量，突然的增减往往意味着业务异常。
4.2 Revaluation与Translation：外币科目的两次处理
如果账套涉及多币种，在Post Journal之后、Period Close之前，要执行Currency Revaluation。这是GL层面的重估，和子模块的外币处理不同。外币重估的目的是把以外币计量的科目余额按期末汇率转换成本位币，并生成汇兑损益分录取证。
Revaluation的操作路径：GL Responsibility → Journals → Revaluation。这里有几个必填参数：
Revaluation Reversal：一般选择Yes，表示下期期初自动冲回本期重估分录，避免余额重复累积。Exchange Rate Type：常用Corporate或User，取决于企业汇率政策。用User意味着你需要提前维护好期末汇率。Revaluation Account：指定汇兑损益科目，这个科目必须在科目结构里存在。Account Range：需要重估的科目范围。实务中通常只重估资产、负债类科目，损益类科目不做重估，否则利润会被汇率波动扭曲。
-- 查询需要重估的外币科目余额 SELECT gcc.segment1 AS company, gcc.segment2 AS account, gcc.segment3 AS currency, gcc.segment4 AS dept, SUM(NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0)) AS opening_balance, SUM(NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)) AS period_activity FROM gl_balances gb, gl_code_combinations gcc WHERE gb.code_combination_id = gcc.code_combination_id AND gb.currency_code <> :p_functional_currency -- 非本位币科目 AND gb.period_name = :p_period_name GROUP BY gcc.segment1, gcc.segment2, gcc.segment3, gcc.segment4 HAVING SUM(NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)) <> 0;这段SQL的用途是发现是否存在外币余额变动。currency_code不是本位币的记录才有重估需求。如果查询结果为0，说明系统里没有外币的余额变动，重估这一步骤可以只跑流程不做实际调整。
重估之后，会生成新的日记帐，这些日记帐需要再次Post。忘记Post重估分录是新手最常见的错误，导致重估后的余额还是旧的。
Translation（外币折算）和Revaluation不一样：Translation用于合并报表场景，把一个实体的本位币账务折算成报告币种。一般只在多公司合并时才需要。如果没有合并报表需求，只需要做Revaluation。
4.3 关账三步走：Close、Close-Close、Permanently Close
当所有日记帐过账完成、重估完成、再次过账完成之后，才进入关账动作。R12的GL期间提供三个关账级别：Close Period、Close-Close Period、Permanently Close Period。理解这三者的区别，你才能决定用哪个。
Close of Period是在GL期间状态从Open变成Closed的行为。关闭之后，普通用户无法再录入或过账到该期间的日记帐，但财务主管可以通过Open Period重新打开期间。这是月结日常使用的选项，每个月末做一遍。
Close-Close of Period是一个更严格的关闭状态。执行Close-Close之后，期间的日记帐过账被严格禁止，即使你是财务主管，也需要先执行Reopen Period才能恢复。它的意义是防止事后有人偷偷改数据。不少企业月结后用Close-Close把期间锁死，但遇到跨期调整时又得重新打开。
Permanently Close是终态，执行之后期间无法再打开。这个操作一般一年做一次，把完全审计结束的年结期间永久关闭。我见过一个有点极端的案例：有企业月结时为了省事，直接把所有历史期间都选了Permanently Close，结果来年发现有张去年的凭证需要改，Treasury那边的银行余额不对，最后只能做重分录冲回再调整，白白多了一堆麻烦。所以我的习惯是：月度关账只做Close，季度或年度视审计节奏做Close-Close，年度审计彻底结束后才做Permanently Close。
-- 查看GL期间当前的关闭状态 SELECT period_name, period_year, period_num, period_type, closing_status, period_status FROM gl_periods WHERE period_type = 'A' AND period_name = :p_period_name;执行顺序在GL界面是：Period Close → Close Period → Close-Close Period。每个操作会弹窗询问确认，确认后可以在GL_PERIODS表里看到CLOSING_STATUS字段从O变成C或F。注意，Close-Close之后，子模块的未处理事务不会受影响，但GL侧无法再补充日记帐。如果子模块还有数据未转移，必须先回子模块处理完毕，否则以后补录只能进下一期。
一个容易被忽略的点：AR和AP的Close-Close和GL的Close-Close要配合做。正确顺序是先AP/AR做Close-Close，再GL做Close-Close，顺序反了会出现GL无法关闭子模块期间的情况。
5. 月结避坑：五个真实翻车记录
5.1 现象：GL Trial Balance不平，AR、AP余额对不上
在月末结账对账时发现，GL的应收余额比AR子模块的期末余额少了，这张差异对不上账。查了所有AR来源的日记帐，也在GL里确认过账了，看起来一切正常。
原因在于AR的Transfer to GL请求没有跑完。Create Accounting已经把分录取证生成好了，但由于并发管理器压力过大，Transfer请求半路终止，导致GL_INTERFACE表里AR数据没有完全进入GL_JE_HEADERS。
解决方法是重新提交Transfer to GL请求。在AR Responsibility的Journals Entry界面，找到Transfer to GL并重新运行。注意，不要重复跑Create Accounting，那样会生成重复分录。重新转移时，接口表里已经存在的数据不会二次导入，系统会自动跳过。如果重新Transfer后还是有差异，查看GL_INTERFACE表的状态和错误消息，把报错记录解决掉。
5.2 现象：Accrue Expense跑完，AP里却没有任何应计分录
月结做AP应计费用，请求状态显示已完成，但打开AP日记帐查询发现没有任何分录，GL里也没有相应的应计金额。
原因出在SLA（Subledger Accounting）的映射配置上。R12里AP的应计分录是通过SLA规则生成的，假如应付模块的会计方法中ACCRUE事件没有配置映射，或者映射到了不存在的科目组合，请求仍然会正常完成，但不会生成任何日记帐，你需要去AP Accounting Options里检查SLA配置。
解决方法是进入Payables Accounting Options，查看Accounting Method，确认其中包含了Accrue Expense事件，并且映射的账户组合在GL科目结构里有效。如果找不到配置，用系统预置的Standard Accrual方法作为基准对照。修改配置后，重新运行Accrue Expense请求，这次产生的分录会在下一个期间或当期显示。提个醒：修改SLA配置只影响修改后的事件，不会追溯历史数据。
5.3 现象：FA折旧已跑，但GL查不到FA的分录
FA模块折旧请求状态为Completed，但GL模块中JE_SOURCE = 'FA'的日记帐数为零。固定资产月结明明已经完成了，总账里却没有折旧费用。
原因是FA的Create Accounting请求没有在折旧后运行。运行折旧只计算了折旧额并更新了FA_DEPRN_DETAIL表，不产生会计分录取证；产生分录取证需要单独运行Create Accounting。折旧和取证的分离是R12的设计，不算缺陷，但确实容易忽略。
解决方法是补跑Create Accounting。在FA Responsibility的Accounting菜单下找到Create Accounting，选择对应的账簿和折旧期间，运行选项里选择Entire Period，生成分录取证。之后还需运行Transfer to GL将分录加入GL。此后确认对应期间FA来源的日记帐数量和金额，和折旧报告比对一致即可。
5.4 现象：外币重估后科目余额不对，差了汇兑损益的金额
执行Currency Revaluation后，查看外币科目的余额，发现本位币金额没有变化，或者说只有一半的调整，汇兑损益没有体现。
原因多数情况是Revaluation之后没有对生成的分录取证进行Post。Revaluation只是生成了重估分录，这些分录若没有Post，就不会影响余额。程序逻辑分两步，但容易让人以为一次请求全搞定。
解决方法是回到Revaluation的批次列表，找到生成的日记帐批次，在GL里Post该批记录。另一个可能性是Revaluation参数设置中Reversal选项选择了Yes，导致重估分录在期初被自动冲回，月末余额看起来没有变化。这时只要确认期末余额是用调整后的汇率计算即可，不必担心期初冲回，那是正确的处理方式。
5.5 现象：Permanently Close点早了，凭证需要调整却改不了
为了赶年度结账进度，把会计期直接Permanently Close，之后发现需要调整一笔重要凭证，但系统提示期间已永久关闭，无法再打开。
原因是Permanently Close是一个不可逆操作，用的时候过于激进。本质上这个操作只适用于年度审计和税务申报彻底结束之后。
解决办法只有一条：如果开了Permanently Close，必须找DBA直接更新GL_PERIODS表的CLOSING_STATUS字段才能恢复，风险较大。更稳妥的做法是在非极端情况下，年度关账最多用Close-Close，给后续留下调整空间。我的个人习惯是月度永远只点Close，季度用一次Close-Close，年度审计完毕后才做Permanently Close。
6. 月结后的验证清单：一个SQL对平五个模块
月结流程跑完之后，账是不是真的平了？我见过最多的问题是“流程全走完了，但数字怎么也和子模块对不上”。所以每次月结收尾，我都会跑一遍跨模块余额核对。这里的思路是：GL作为总账，它应该等于各子模块的汇总。AP应付、AR应收、FA固定资产折旧，全部要映射到GL的对应一级科目。只要对平了，这个月才算真正关干净。
-- 月结后核验：GL当期余额与子模块余额一致性检查 SELECT alg.ledger_id, alg.period_name, alg.account_code, alg.account_description, NVL(alg.begin_balance_dr - alg.begin_balance_cr, 0) AS opening_balance, NVL(alg.period_net_dr - alg.period_net_cr, 0) AS period_activity, NVL(alg.end_balance_dr, 0) - NVL(alg.end_balance_cr, 0) AS closing_balance FROM ( SELECT gb.ledger_id, gb.period_name, gcc.concatenated_segments AS account_code, gcc.description AS account_description, gb.begin_balance_dr, gb.begin_balance_cr, gb.period_net_dr, gb.period_net_cr, gb.end_balance_dr, gb.end_balance_cr FROM gl_balances gb, gl_code_combinations gcc WHERE gb.code_combination_id = gcc.code_combination_id AND gb.period_name = :p_period_name AND gb.actual_flag = 'A' AND gcc.segment2 LIKE '1%' -- 假设资产类科目段范围，按实际科目结构调整 ) alg ORDER BY alg.account_code;这段SQL查询的是GL的gl_balances表的期末余额，是月结后最容易上手的验证工具。查出来的结果要和AP、AR、FA各子模块的报表做横向对比。实际操作中，你可以再写一个子查询，分别把AP的日记帐余额、AR的日记帐余额、FA的折旧费用余额输出来，然后按科目段拼接比对。但不要指望系统能自动告诉你“对不上”，EBS没有这样一个一键对账的报表，你得自己有好的方法。
我最后留着的一个习惯是：月结完成后，把当月的Trial Balance和Period Close Exception Report导出存档，至少保留两年。这样即使以后需要追溯某个期间的余额是怎么来的，不用重新打开早已关闭的期间，还能快速定位是哪个步骤出了问题。如果审计来查，也有完整的证据链。这是我从第一年上线翻车后养成的习惯，到现在都觉得值得。希望帮到你。
本文还有配套的精品资源，点击获取
