从 SAP 取数到 CN VAT 月结自动化From SAP Data to CN VAT Month-End Automation
业务出身的方案人：深入一线定义问题，先算账量化价值，再以数据产品和 AI 能力落地——走过「场景挖掘 → 需求定义 → 落地 → 效果验证 → 方法论沉淀」完整闭环，并在每个关账周期里循环进化。A business-native builder: define the problem on the front line, quantify the value first, then land it with data products and AI capabilities — through the full loop of scenario mining, requirement definition, delivery, verification and consolidation, still evolving every close cycle.
先算账：手工核对 ≈ 2–3 人天/月·实体 × 约 10 家实体 ≈ 全年数百人天耗在肉眼核对上，叠加合规风险敞口——这笔账既是立项的依据，也是效果验证的基线。Numbers first: manual reconciliation ≈ 2–3 person-days per entity-month × ~10 entities ≈ hundreds of person-days a year on eyeball checking, plus compliance exposure — the case that justified the project, and the baseline we verify against.
↺ 回到 ①：下一个关账周期，带着更准的规则回到业务实践↺ Back to ①: the next close cycle returns to business practice with sharper rules
例 1 · N:N 撮合Example 1 · N:N matching一凭证对多票，多凭证合一票One voucher to many invoices — and the reverse
分批到票、部分冲销、跨期挂账——人工肉眼核对是月结最大瓶颈。Invoices arriving in batches, partial write-offs, cross-period items — manual eyeball matching is the biggest month-end drag.
↳ 多维权重引擎自动锁定对应关系，对不上的按差异原因归类，人只看例外。↳ The weighting engine auto-locks the pairing; unmatched items are grouped by cause — people review only exceptions.
例 2 · 红冲与跨期Example 2 · Reversals & cross-period上月已认证，本月红冲了Certified last month, reversed this month
发票状态一直在变，但审计要求能还原「当时那一刻」的账票状态。Invoice states keep changing, yet audit requires reconstructing the exact state at any past moment.
↳ SCD 建模保存完整生命周期，任意时点还原审计快照。↳ SCD modeling keeps the full lifecycle; audit snapshots restore any point in time.
例 3 · 跨实体 ICExample 3 · Intercompany (IC)A 已开票，B 未认证Entity A invoiced, Entity B hasn't certified
关联方之间销项与进项认领节奏脱节，集团申报存在单据脱节风险。Output vs input VAT claim rhythm falls out of step across related parties — a group-filing risk.
↳ AR vs AP 自动比对，申报前拦截跨实体单据脱节。↳ AR vs AP compared automatically; cross-entity disconnects intercepted before filing.
约 10 家~10 entities集约化覆盖法人实体Legal entities covered by centralization
6+ 个周期6+ cycles稳定运行的月结关账Stable month-end close cycles
↺ 例外变成规则 · 匹配更加自动 · 功能自己长出来↺ Exceptions become rules · matching gets more automated · features grow themselves
Project Case · 财务 × 数据工程Project Case · Finance × Data Engineering
从 SAP 取数到 CN VAT 月结自动化From SAP Data to CN VAT Month-End Automation
一场 N:N 账票撮合的攻坚战Tackling the N:N Invoice-to-Voucher Matching Problem
业务出身（财务一线）的 FDE 实践复盘：深入一线定义问题、先算账量化价值，再以数据产品和 AI 能力落地，
走过「场景挖掘 → 需求定义 → 落地 → 效果验证 → 方法论沉淀」完整闭环。本项目就是闭环的一次完整演练——以 Excel 数值原型
破冰萃取业务规则，与 IT 共建 Fabric 湖仓流水线，用 PySpark 撮合引擎攻克 N:N 账票对账，并借集团集约化延伸出 IC 跨实体对账。A retrospective from a business-native FDE (finance front line): define the problem on the ground,
quantify the value before building, then land it with data products and AI capabilities — through the full loop of
scenario mining, requirement definition, delivery, effect verification, and methodology consolidation. This project
ran that loop end to end: an Excel numeric prototype extracted the rules, a Fabric lakehouse pipeline was co-built
with IT, and a PySpark weighting engine conquered N:N invoice–voucher matching, later extended into IC intercompany
reconciliation via group centralization.
Koch ｜ 财务转型创新岗 · FDE 实践 ｜ SAP · Microsoft Fabric · PySparkKoch | Finance Transformation & Innovation · FDE Practice | SAP · Microsoft Fabric · PySpark
中国增值税严格按月申报：进项税认证勾选、销项税开具、GL 总账税金科目对账、申报底稿编制，一样不能少。
传统流程里这些活分散在各法人实体的财务手里——手工导出 Excel、拼接、肉眼核对，每到月结就是一场高压作业。China VAT is filed strictly by month: input VAT certification & selection, output VAT invoicing,
GL tax-account reconciliation, and filing working papers — none can be skipped. Traditionally these tasks sit with
the finance staff of each legal entity: manually exporting Excel, stitching sheets, eyeball-checking lines. Every
month-end becomes a high-pressure operation.
1
先算账 · 立项依据Run the numbers first
手工核对 ≈ 2–3 人天/月·实体 × 约 10 家实体 ≈ 全年数百人天耗在肉眼核对上，再叠加合规风险敞口——这笔账既是立项的依据，也是效果验证的基线。Manual reconciliation ≈ 2–3 person-days per entity-month × ~10 entities ≈ hundreds of person-days a year on eyeball checking, plus compliance exposure — the case that justified the project, and the baseline to verify against.
瓶颈账 · N:N 账票撮合The bottleneck: N:N matching
单笔凭证对应多张发票、多笔凭证合并一张发票，还有部分冲销与跨期挂账的极端场景——人工肉眼核对是月结效率的最大瓶颈。One voucher maps to multiple invoices, multiple vouchers merge into one invoice, plus partial write-offs and cross-period items — manual eyeball matching is the single biggest drag on month-end efficiency.
合规风险Compliance risk
漏勾、错配直接构成申报合规风险，越是赶时间越容易出错。Missed selections and wrong matches are direct filing-compliance risks — and the tighter the deadline, the more errors happen.
信息孤岛Information silos
单法人视角各管一段，集团看不见跨实体全貌。Each legal entity sees only its own slice; the group has no cross-entity view.
原型PrototypeSTAGE 02 · HOW ①
Excel 原型破冰Breaking the ice with an Excel prototype
我没有坐等一份完美的 PRD，而是凭财务底子直接用 Excel 搭了一版带真实业务数据流的 Draft Demo：
数字从哪里来、按什么逻辑算、需要业务提供什么主数据，一页看得明明白白。I didn't wait for a perfect PRD. With my finance background, I quickly built an Excel draft demo
wired to a real business data flow: where each number comes from, what logic computes it, and what master data
the business must provide — all clear on one page.
2
方法 · 建设性对抗Method: constructive pushback
初始草案几乎每条都被业务「反对」😂——但正是反对把隐性业务规则和特殊例外一条条逼了出来，具象的 Demo 击破了沟通迷雾。Nearly every line of the first draft was "objected to" by the business 😂 — and those objections surfaced hidden rules and edge exceptions one by one. A concrete demo cut through the communication fog.
产出 · Master 规则库Output: the master rule library
高频迭代沉淀出整个系统的业务规则底座。High-frequency iteration produced the business-rule foundation of the entire system.
架构ArchitectureSTAGE 03 · HOW ②
携手 IT 定架构Designing the architecture with IT
技术方案的难点，我带着 Data Demo 主动找内部 IT 架构师高频研讨。
最硬的一仗是给发票建生命周期模型：一张票从开具、认证到跨期作废、红冲，状态一直在变。For the hard technical calls, I brought the data demo to internal IT architects for high-frequency
working sessions. The toughest battle was modeling the invoice lifecycle: a single invoice moves through issuance,
certification, cross-period voiding and red-letter reversals — its state keeps changing.
3
决策 · SCD 建模Decision: SCD modeling
落地缓慢变化维（SCD）方案：兼顾计算性能与「月结历史审计快照还原」（Audit Trail）——任何时点都能还原当时的账票状态。Landed a slowly-changing-dimension (SCD) design balancing compute performance with "historical audit snapshot restoration" (Audit Trail) — any point in time can be reconstructed.
系统 · SAP 源头System: SAP as the source
GL 总账、发票与凭证数据统一取自 SAP。GL, invoices and vouchers all come from SAP.
权衡The trade-off
纯快照查得快，但存不下历史；SCD 让「算得动」与「查得回」两全。Pure snapshots read fast but lose history; SCD delivers both "fast to compute" and "possible to trace back".
流水线PipelineSTAGE 04 · HOW ③
数据流水线落地Building the data pipeline
架构敲定就开搭流水线：以 Microsoft Fabric 湖仓为底座，Data Factory 全流程自动编排月度数据拉取与批处理——
从 SAP 取数到入库，不再有手工导出。With the architecture settled, we built the pipeline on a Microsoft Fabric lakehouse: Data Factory
orchestrates the monthly data pull and batch processing end to end — from SAP extraction to landing, no more
manual exports.
4
工具 · Data Factory PipelineTool: Data Factory Pipeline
月度取数与批处理自动编排，异常自动暴露。Automated orchestration of monthly extraction and batch runs; failures surface automatically.
系统 · SAP 标准连接器System: SAP standard connectors
标准连接器直连取数，稳定可靠，免去接口定制。Direct extraction via standard connectors — stable, reliable, no custom interface work.
产出 · 数据侧零手工Output: zero manual data work
每月定时跑批，为撮合引擎备好干净数据。Scheduled monthly batch runs stage clean data for the matching engine.
算法AlgorithmSTAGE 05 · HOW ④
N:N 撮合引擎The N:N matching engine
项目最核心的攻坚在算法：我在 Synapse Notebook 里用 PySpark 写下多维权重匹配引擎，
把「肉眼对不清」的 N:N 撮合交给机器。The core battle was the algorithm: in a Synapse Notebook I wrote a multi-dimensional weighting
matching engine in PySpark, handing the "impossible to eyeball" N:N matching over to the machine.
5
算法 · 多维权重匹配Algorithm: multi-dimensional weighting
把 Master 规则库里的匹配依据变成可计算的打分维度，从海量组合中锁定最可能的凭证–发票对应关系。Matching criteria from the master rule library become computable scoring dimensions that pick the most likely voucher–invoice pairing out of massive combinatorial space.
场景 · 全覆盖Coverage: every scenario
1:N、N:1、N:N、部分冲销、跨期挂账，全部纳入引擎处理范围。1:N, N:1, N:N, partial write-offs and cross-period items are all within the engine's scope.
输出 · 差异分类Output: classified differences
自动撮合结果之外，对不上的按差异原因归类，直奔人工处理。Beyond auto-matched results, unmatched items are grouped by difference cause and routed straight to human handling.
工程EngineeringSTAGE 06 · HARDENING
工程化打磨Engineering hardening
一个每月都要跑的系统，必须「改得起、信得过」。我做了两件事：让规则可配置，让错误可解释。A system that must run every month has to be "cheap to change and easy to trust." I did two
things: make rules configurable, and make errors explainable.
6
设计 · Meta-Driven ViewsDesign: meta-driven views
Master-file 配置驱动 T-SQL 视图生成，彻底杜绝硬编码：未来税制或科目微调，改配置即可，零代码改动自适应。A master file config drives T-SQL view generation — zero hardcoding. Future tax-rule or account tweaks adapt through configuration alone, with no code changes.
闭环 · 规则校验循环Loop: rule verification cycle
每次运行自动输出错误明细与原因诊断，规则漏洞当期修复；考虑可靠性，采用纯规则校验，不引入模型。Every run outputs error details with cause diagnosis, so rule gaps get fixed within the same cycle. For reliability, verification is pure rules — no models involved.
共创Co-creationSTAGE 07 · SCALE
共创飞轮与集约化The co-creation flywheel & centralization
当 SME 看到草案真的长成可运行的系统，信任建立了。业务开始主动反哺：「能不能加个 IC 预警？」「待抵扣能不能自动跟踪？」
恰逢集团集约化拉通多法人实体，IC 跨实体对账顺势落地。When SMEs saw the draft grow into a running system, trust followed. The business began feeding
back requirements proactively: "Can we add an IC alert?" "Can pending deductions be tracked automatically?"
Group centralization then pulled all legal entities onto one platform, and IC intercompany reconciliation
landed naturally.
7
功能进化 · IC 对账Feature evolution: IC reconciliation
自动比对关联方 AR vs AP、销项税与进项税认领节奏，申报前拦截跨实体单据脱节风险。Automatic comparison of intercompany AR vs AP and of output-vs-input VAT claim rhythm, intercepting cross-entity document disconnects before filing.
理念 · Adopted SolutionPrinciple: adopted solution
业务深度参与创造的系统才会被持续使用——从单点工具长成核心资产。A system co-created with the business is a system people keep using — a single-purpose tool grows into a core asset.
流程 · 集约化Process: centralization
打破单法人信息孤岛，集团统一申报口径与数据底座。Breaking single-entity silos with a unified group-level filing scope and data foundation.
成果ValueSTAGE 08 · VALUE
月结新常态The new month-end normal
现在的每月关账：系统跑完勾选、撮合、对账与底稿，人只处理差异和例外。
原来一场「高压作业」，变成流程稳定的常规操作。Now every monthly close: the system runs selection, matching, reconciliation and working papers;
people handle only differences and exceptions. A "high-pressure operation" has become a stable, routine process.
8
价值 · 周期压缩Value: compressed cycles
对账与出表从 2–3 人天缩至小时级。Reconciliation and reporting shrank from 2–3 person-days to hours.
防线 · 审计保障Defense: audit assurance
N:N 匹配与 IC 拦截前移，构筑税务审计防线。N:N matching and IC interception moved risk checks upstream, building a solid tax-audit line of defense.
证据 · 实物见下Evidence: see below
调度流图与监控看板截图见「交付成果」区。Scheduler and dashboard screenshots are in the Deliverables section.
Iteration Flywheel
迭代飞轮：实践—认识—再实践—再认识The iteration flywheel: practice — cognition — practice again
我们做的不是一个"一次性交付"的项目：从业务中抽象出规则，又从新的实践中优化规则。系统上线不是终点——每个关账周期都是一圈新的"实践、认识、再实践、再认识"，规则更准，系统更强。This was never a one-shot delivery: we abstracted rules from the business, then refined those rules through new practice. Go-live was not the end — every close cycle turns the loop of practice, cognition, and practice again, sharpening rules and strengthening the system.
↺ 回到 ①：下一个关账周期，带着更准的规则回到业务实践↺ Back to ①: the next close cycle returns to business practice with sharper rules
例外变成规则Exceptions become rules特殊场景逐条沉淀进 Master 规则库，覆盖面一圈比一圈宽Edge cases accumulate into the master rule library, widening its coverage cycle by cycle
匹配更加自动Matching gets more automated自动化率与准确率随每个周期爬升，人工只看真正的差异Automation rate and accuracy climb every cycle; people review only real differences
功能自己长出来Features grow themselvesIC 对账、待抵扣跟踪均由业务反哺催生，而非预先规划IC reconciliation and pending-deduction tracking grew from business feedback, not upfront planning
图 2 · 业务采纳度 —— 每个关账周期实际在用的产出Fig. 2 · Business adoption — outputs actually used every close cycle
月结周期极大压缩Month-end cycle drastically compressed
繁复的手工核对与出表耗时大幅缩减至小时级，显著降低月结关账高压。Laborious manual reconciliation and reporting cut to hours, sharply reducing close pressure.
N:N 匹配与 IC 风险前移拦截N:N matching & IC risk intercepted upstream
复杂对账自动化率与准确率跃升，消除人工肉眼核对盲区，构筑严密的税务审计防线。Automation rate and accuracy jumped, manual blind spots eliminated — a strict tax-audit line of defense.
深度采纳的生产力平台A deeply adopted productivity platform
不是交付即弃的「面子工程」：每个关账周期稳定运行，业务持续共创、深度依赖。Not a shelf-ware "face project": it runs reliably every close cycle, co-created with and deeply relied on by the business.
FDE Playbook
FDE 方法论沉淀FDE playbook
① 场景挖掘1 · Scenario mining深入一线，盘点月结困局Front-line discovery of the close bottleneck
不等完美 PRD：用带真实数据流的 Excel Demo 换取「建设性反对」，让隐性规则与例外显性化，高频迭代成 Master 规则库。Skip the perfect PRD: an Excel demo wired to real data flows earns "constructive pushback" that surfaces hidden rules and exceptions, iterated into a master rule library.
02
带着 Data Demo 论证架构Argue architecture with a data demo
空对空的架构讨论效率最低。带着数据与 IT 高频研讨，SCD 选型一次到位——兼顾计算性能与审计快照还原。Architecture debates without data go nowhere. Bringing numbers to IT working sessions settled SCD selection in one go — balancing compute performance and audit snapshot restoration.
03
零硬编码的元数据设计Metadata design, zero hardcoding
Master-file 配置驱动视图生成：税制、科目未来怎么变，系统就怎么自适应，零代码改动。Master-file config drives view generation: however tax rules and accounts change, the system adapts through configuration — zero code changes.
04
共创飞轮The co-creation flywheel
先让业务看见可运行的系统，信任带来主动反哺——需求自己长出来，工具从单点长成被采纳的核心资产。Let the business see a running system first; trust brings proactive feedback — requirements grow themselves, and a tool grows into an adopted core asset.
My Role & Skill Set · Molex CN VAT 项目My Role & Skill Set · Molex CN VAT Project
我在项目里的角色与技能集My Role & Skill Set in the Project
以推动财务数字化转型为目标的 FDE 实践：业务出身（财务一线）的我，在一个项目里先后戴上需求分析师 → 产品经理 → 数据架构师 → 开发 → 实施的帽子——深入一线定义问题、先算账量化价值，再以数据产品落地；每一步都有明确交付与可迁移的财税数字化能力沉淀。An FDE practice built to drive financial digital transformation: business-native (finance front line), I wore Business Analyst → Product Manager → Data Architect → Developer → Implementation hats across one project — defining the problem on the front line, quantifying the value first, then landing it as a data product, with a clear deliverable and transferable finance-digitisation capability at every step.
背景 BackgroundBackground
税务部门对 VAT 申报的准确性、可追溯性、合规性与数据颗粒度要求不断提高，需以标准化、自动化方案替代碎片化的手工底稿，并能处理更大的数据量。Rising expectations from the tax bureau for filing accuracy, traceability, compliance and data granularity created the need to replace fragmented manual workpapers with a standardised, automated solution capable of processing larger data volumes.
项目 ProjectProject
通过 Microsoft Fabric 与可配置规则，交付进项 VAT、销项 VAT、以及 CIT/VAT 收入的整合对账。The project delivers integrated input VAT, output VAT, and CIT/VAT revenue reconciliation through Microsoft Fabric and configurable rules.
①
需求分析师 · BABusiness Analyst需求收集Demand Collection
我的角色My role通过评估现有流程与相关方需求，定义项目范围与目标。Defined scope and objectives by assessing current processes and stakeholder needs.
·流程发现Process discovery·业务分析Business analysis·税法流程理解Tax process understanding·数据血缘与口径对齐Data lineage & definition alignment
具体做了什么What I actually did
走访各法人实体财务，把月结对账拆成进项认证 / 销项 / GL 税金科目 / 申报底稿四段，逐段摸清卡点Interviewed each entity's finance team and split the close into input certification / output / GL tax / filing, pinpointing each bottleneck.
识别出真痛点：税局已把申报细度从发票层级提到发票明细行级，手工 Excel + 人工撑不住Spotted the real driver: the tax bureau had raised filing granularity from invoice level to line-item level — manual Excel plus people could not cope.
拿到两个具体反例：未开票收入对不上→挂账遗留、固定资产整张发票虚报Captured two concrete cases: unreconciled unbilled revenue lingering on the books and whole-invoice fixed-asset overstatement.
②
产品经理 · PMProduct Manager目标对齐Outcome Alignment
我的角色My role把用户想法转成看得见的需求，并主动邀请早期质疑。Translated user ideas into visible requirements and invited early challenge.
把财务语言转成可验收口径：如「明细行级对账通过率」「未开票收入按月连续追踪」Turned finance language into verifiable definitions — e.g. "line-item match rate", "unbilled revenue tracked continuously by month".
用 Excel 原型把「看清发票里每个物件」可视化，主动邀请业务反对，逼出隐性规则与例外Visualised "see every item in the invoice" in an Excel prototype and invited pushback, surfacing hidden rules and edge cases.
对齐已开票 / 未开票 / 部分资本化的界定Aligned the definition of billed / unbilled / partially capitalised.
③
数据架构师Data Architect设计与决策Design & Decide
我的角色My role定义端到端架构，并针对关键挑战评估可选方案。Defined end-to-end architecture and evaluated options for key challenges.
定义端到端架构：SAP 取数 → 湖仓 → 撮合 → 元数据视图 → 底稿 / 看板Defined the end-to-end architecture: SAP extraction → lakehouse → matching → metadata views → working papers / dashboards.
决策 1：发票生命周期用 SCD 建模——支撑「未开票收入 by month 持续追踪」与「任意时点还原申报状态」Decision 1: SCD modelling for the invoice lifecycle — enabling by-month unbilled-revenue tracking and any-time state reconstruction.
决策 2：固定资产做行级资本化拆分，只把应资本化的行计入底稿，不再整张虚报Decision 2: line-level capitalisation split for fixed assets — capitalise only the eligible lines, no whole-invoice overstatement.
对象建模：把发票 / 明细行 / 凭证 / 状态定义为标准对象与关系Object modelling: defined invoice / line / voucher / state as standard objects and relations.
搭 Fabric 湖仓流水线，Data Factory 月度自动取数，数据侧零手工Built the Fabric lakehouse pipeline with automated monthly ingestion via Data Factory — zero manual data work.
写 PySpark 撮合引擎：按发票明细行粒度做金额守恒的 N:N 匹配（税号 / 金额 / 日期 / 供应商多维打分）Wrote the PySpark matching engine: line-item-level, amount-conserving N:N matching (multi-dimensional scoring on tax ID / amount / date / vendor).
用 Master-file 配置驱动 T-SQL 视图生成（零硬编码），把「部分资本化」「未开票收入追踪」做成可配置规则Drove master-file-configured T-SQL views (zero hardcoding), turning "partial capitalisation" and "unbilled-revenue tracking" into configurable rules.
落地未开票收入连续追踪表——可查每笔票最早申报时间与状态，替代「对不上就搁置」Landed a continuous unbilled-revenue tracking table — trace when each invoice was first declared and its status, replacing "leave it if it doesn't match".
⑤
实施顾问Implementation评估与测试Evaluation & Testing
我的角色My role设计高效的验收流程，实现快速验证。Designed an efficient acceptance process for rapid validation.
·可扩展思维Scalable thinking·用 Copilot in Excel 高效提示Effective prompting via Copilot in Excel
具体做了什么What I actually did
设计验收流程：拿真实月结数据回归，自动匹配结果 vs 人工抽检比对Designed the acceptance flow: regression on real close data, comparing auto-match results against manual sampling.
建立「对不上的差异分类 + 原因诊断」，异常自动暴露给业务Built "difference classification + cause diagnosis", surfacing anomalies straight to the business.
上线支持并培训财务，每期关账跟踪匹配率 / 差异数 / 周期时长Ran go-live support and finance training, tracking match rate / differences / cycle time each close.
复杂业务场景 · 关键难点与应对Complex Business Scenarios · Challenges & Response
场景 1 · N:N 拆分与分摊Sc.1 · N:N split & apportion一张凭证对多张发票，金额要按比例分摊到明细行One voucher to many invoices, amounts apportioned to line items
难点：Challenge:到货分批、开票分批，多对多组合爆炸；每一笔必须金额守恒——分摊后加总等于总额，稍有出入即构成申报差异。Arrivals and invoicing come in batches, so the N:N combination space explodes; every match must be amount-conserving — the apportioned lines sum to the total, and any deviation is a filing difference.
应对：Response:把「凭证—发票—明细行」定义为标准业务对象与关系（对象建模、口径对齐）；把匹配依据规则数据化成多维打分；再用硬约束（金额守恒、税号一致）筛除、软排序（权重打分）推荐，输出可解释的匹配与匹配原因，对不上的自动归类为差异。Model voucher–invoice–line as standard business objects & relations (object modeling, definition alignment); turn matching criteria into data-driven multi-dimensional scoring; then use hard constraints (amount conservation, matching tax IDs) to filter and soft ranking (weights) to recommend, outputting explainable matches and reasons, and auto-classifying the unmatched as differences.
场景 2 · 跨期红冲与暂估Sc.2 · Reversal & accrual across periods上月已认证、本月红冲；发票未到先暂估入账、次月冲回Certified last month, reversed this month; accrual before invoice, reversed next month
难点：Challenge:发票状态持续变化，但审计要求还原「当时那一刻」的账票状态；红冲/进项转出/暂估冲回的认定口径不一致会直接算错。Invoice states keep changing, yet audit demands reconstructing the exact state at a past moment; any mismatch in the recognition definition of reversal / input-output / accrual-return skews the result.
应对：Response:用 SCD 建模保存完整凭证生命周期、任意时点还原审计快照；与财务对齐「暂估 / 红冲 / 进项转出」的认定与冲回口径（口径统一）；跑批时锁定当月时点快照。Model the full voucher lifecycle with SCD so any point in time is reconstructible; align the recognition & reversal definitions for accrual / reversal / input-output with finance (definition alignment); pin the current-period snapshot at batch time.
场景 3 · 关联方互开发票与节奏错配Sc.3 · Intercompany invoice & rhythm mismatch集团内 A 已开票、B 未认证的 IC 错配Entity A invoiced, Entity B not yet certified (IC mismatch)
难点：Challenge:跨实体数据分散在不同账套；追踪 buyer→seller 记录缺少统一主键，销项/进项认领节奏一脱节就构成申报风险。Cross-entity data lives in different ledgers, and tracing buyer→seller records lacks a common master key — once the output/input claim rhythm falls out of step, it becomes a filing risk.
应对：Response:遵循 SAP 记账模式建立关联方钩稽关系（主数据统一）；AR vs AP 自动比对、销项/进项认领节奏比对；申报前拦截跨实体单据脱节。Follow SAP posting patterns to build intercompany reconciliation links (master-data unification); auto-compare AR vs AP and output/input claim rhythm; intercept cross-entity disconnects before filing.
难点：Challenge:异常与差异往往藏在数据细节里，触发逻辑散落在各计税口径中，肉眼根本扫不过来。Anomalies and gaps hide in the data details, with trigger rules scattered across taxing definitions — impossible to eyeball.
应对：Response:从异常数据反查根因（业务过程分类→口径统一→主数据统一）；把识别规则配置进规则库（零硬编码）；纯规则校验输出错误明细与原因诊断，异常直接暴露给业务。Trace anomalies back to root causes (business-process classification → definition unification → master-data unification); codify the detection rules into the rule library (zero hardcoding); and use pure rule-based checks that output error details with cause diagnosis, surfacing anomalies straight to the business.
场景 5 · 申报细度提升到明细行Sc.5 · Filing granularity to line item税局把申报细度从发票层级，提到「发票里的每个物件」The tax bureau raised filing granularity from invoice level to "every item in the invoice"
难点：Challenge:一张发票多物件，手工 Excel 只能对到发票级、撑不住行级核算，行与行之间也没钩稽——粒度根本达不到。One invoice holds many items; manual Excel could only reconcile to invoice level, not line level, and lines had no audit trail between them — the granularity was simply unattainable.
应对：Response:把发票建模到明细行（对象建模、口径对齐）；撮合引擎按行级做金额守恒匹配；规则库支持行级拆分与核对，申报直接落到行。Model the invoice down to line item (object modelling, definition alignment); the engine matches at line level with amount conservation; the rule library supports line-level split & reconciliation, so filing lands at the line.
场景 6 · 未开票收入按月持续追踪Sc.6 · Unbilled revenue tracked by month未开票收入要按月陈列，且需持续追踪每笔票的历史状态Unbilled revenue listed by month, tracking each invoice's history
难点：Challenge:手工对不上的那部分往往就挂账不清，一直遗留在账上；也答不出「这笔票最早什么时候申报、什么状态」。The unmatched portion often just stays on the books, unreconciled, forever; and no one can answer "when was this invoice first declared, and in what state".
应对：Response:把未开票收入做 by month 连续系统记录（对象建模 + 逐月累积），随时可查每笔票的历史申报状态；连续记录取代「对不上就搁置」，杜绝长期挂账。Keep a continuous by-month record of unbilled revenue (object modelling + month-by-month accumulation), so any invoice's declared history is queryable; the continuous record replaces "leave it if it doesn't match", ending long-stale balances.
场景 7 · 固定资产行级资本化拆分Sc.7 · Line-level capitalisation split发票里只有 20 块是固定资产，手工却把整张 100 块都报进去Only ¥20 of a ¥100 invoice is fixed asset, but manual reporting booked the whole ¥100
难点：Challenge:从同一供应商一次买一堆东西一起开票，仅一小部分进入固定资产底稿；手工整张报 → 虚增固定资产金额。Buying a bundle from one vendor is invoiced together, yet only a slice belongs in the fixed-asset working paper; reporting the whole invoice overstates fixed-asset value.
应对：Response:行级资本化拆分（规则数据化）：只把应资本化的行计入固定资产底稿，其余进费用；用规则库显式界定哪些行资本化，避免虚增。Line-level capitalisation split (rules as data): capitalise only the eligible lines into the fixed-asset working paper, expenses elsewhere; the rule library states explicitly which lines capitalise, avoiding overstatement.
关键挑战与方案Key Challenges & Solutions
复杂撮合Complex matching
为多种对账场景构建可配置规则，让用户能轻松审阅并挑战逻辑。Built configurable rules for diverse reconciliation scenarios, enabling users to review and challenge the logic easily.
关联方Intercompany
遵循 SAP 记账模式，跨实体把采购方发票追溯到销售方记录。Follow SAP posting patterns to trace buyer invoices to seller-side records across entities.
缓慢变化维Slow Change Dimension
寻求资深 IT 指引，为不断变化的发票与对账状态选择合适的时态模型。Sought senior IT guidance to select a historical model for changing invoice and reconciliation statuses.
成果 OutcomesOutcomes
进项 VAT 对账细化到发票与发票行级。Input VAT reconciliation at invoice and invoice-line levels.
一套集中化、可配置的方案，提升跨实体的效率、数据质量、透明度与风险识别。A centralised, configurable solution improving efficiency, data quality, transparency, and risk identification across entities.
未来改进Future Improvement
项目验证了「可配置规则 + 撮合引擎」这条路，下一步是把单点成功变成体系能力，推进财务数字化转型：The project proved the "configurable rules + matching engine" path; the next step is turning a single success into platform capability and driving financial digital transformation:
纵深Deepen从 VAT 对账延伸到进项 / 销项 / 申报 / CIT 的全链路闭环，覆盖更多税种与业务场景，夯实「单据—账—税」一致。Extend from VAT reconciliation to a full loop across input/output VAT, filing and CIT, covering more tax types and scenarios while reinforcing document–ledger–tax consistency.
横向Widen把规则底座与撮合引擎沉淀为可复用的财务数字化资产，滚动推广到更多法人实体与业务板块，支撑集团财税集约化。Codify the rule foundation and matching engine into reusable financial-digital assets, rolling them across more legal entities and segments to support group tax centralisation.
团队赋能Team enablement方法论转成文档、模板与规则库，向财务团队持续转移——月结从「靠个别人」变成「靠机制、靠流程」，财务从手工核对中解放出来，投到更高价值的分析与经营支持。Convert the methodology into documents, templates and rule libraries and transfer it to the finance team — shifting month-end from "a few individuals" to "mechanisms and process", and freeing finance from manual reconciliation into higher-value analysis and decision support.
把模糊的业务问题翻译成被采纳的 AI / 自动化 / 数据 / 软件解决方案——这是 FDE 的使命，也是我要讲的项目。以下逐字稿已按这个 JD 的关键词逐条对齐：可直接照读，也可当 STAR 提纲。Translate ambiguous operational problems into adopted AI, automation, data, or software solutions — that is the FDE mission, and the project I will walk through. This script is aligned keyword-by-keyword to the JD: read it as-is, or use it as a STAR outline.
ROLE / MISSIONROLE / MISSION
Forward-Deployed Engineer / Solution Lead —— 把模糊的运营问题，翻译成被采纳的 AI / 自动化 / 数据 / 软件解决方案。Forward-Deployed Engineer / Solution Lead — translate ambiguous operational problems into adopted AI, automation, data, or software solutions.
WHAT TO RECRUIT FORWHAT TO RECRUIT FOR
业务敏锐度、学习敏捷、系统思维、技术可信度、判断力、owner 意识；赢得 SME 与高管信任。避开「只会交付的顾问」和「框不住业务的纯技术」。Business acumen, learning agility, systems thinking, technical credibility, judgment, ownership; earn SME and executive trust. Avoid pure consultants who cannot deliver and pure technologists who cannot frame the business problem.
① 对准 KEY SKILLS · 逐字回答① Aligned to KEY SKILLS · verbatim answers
业务问题界定Business problem framingKEY SKILL
我习惯先算账。立项前我把手工核对量化成 2–3 人天/月·实体 × 约 10 家 ≈ 全年数百人天，再叠加合规风险敞口——这就是问题有多大的最硬证据，也是后面效果验证的基线。I frame problems by running the numbers first. Before scoping I quantified manual reconciliation at 2–3 person-days per entity-month × ~10 entities ≈ hundreds of person-days a year, plus compliance exposure — the hardest evidence of how big the problem is, and the baseline I verify against later.
流程分析Workflow analysisKEY SKILL
我把月结流程拆到能动手的颗粒度：进项认证勾选、销项开票、GL 税金科目对账、申报底稿编制，逐段盘点卡在哪、为什么慢。瓶颈很快锁死在 N:N 账票撮合。I took the close process apart to a granularity I could act on: input certification & selection, output invoicing, GL tax-account reconciliation, filing working papers — pinpointing where each segment stalls and why. The bottleneck was quickly pinned on N:N invoice-voucher matching.
产品思维Product thinkingKEY SKILL
我没等一份完美 PRD，先做用户能反应的产物：一页看懂数字从哪来、按什么逻辑算、需要什么主数据。具象的 Demo 把隐性规则和例外一条条逼了出来。I did not wait for a perfect PRD — I built something the user could react to: one page showing where numbers come from, what logic computes them, and what master data is needed. A concrete demo surfaced hidden rules and edge cases one by one.
解决方案架构Solution architectureKEY SKILL
架构最难的一仗是发票生命周期建模。我带着数据 Demo 和 IT 架构师高频研讨，落地 SCD——兼顾计算性能与「任意时点还原审计快照」，而不是一句「用历史表」带过。The hardest architectural call was modeling the invoice lifecycle. I brought a data demo to IT architects for high-frequency sessions and landed on SCD — balancing compute performance with "restore the audit snapshot at any point in time," not waving it off with "just use a history table."
快速原型Rapid prototypingKEY SKILL
一周内搭出带真实业务数据流的 Excel Demo，从启动到第一版 Draft Demo。快不是目的，是为了让业务尽早反应、尽早「反对」。Within a week I built an Excel demo wired to real business data, from kickoff to a first draft demo. Speed was not the goal — it was to get the business to react and push back early.
引导协作FacilitationKEY SKILL
我把财务、业务、SME、IT 拉到同一张桌子。每版草案都故意邀请「反对」——那些反对意见，正是 Master 规则库的地基。I got finance, business, SMEs and IT around the same table. Every draft deliberately invited pushback — those objections were the foundation of the master rule library.
向上与高管沟通Executive communicationKEY SKILL
跟管理层我讲「账」不讲「功能」：这个问题值多少人天、方案投入多大、回报什么时候兑现。价值可量化，立项和资源就顺了。With leadership I speak in numbers, not features: how many person-days the problem costs, what the solution costs, and when the value lands. Quantified value makes scoping and resourcing straightforward.
价值兑现Value realizationKEY SKILL
上线后我盯的是结果不是交付：对账出表从 2–3 人天缩到小时级，N:N 匹配率 ≥ 90%，对不上的自动按差异归类。价值是「用出来的」，不是「交付完就完」。After go-live I measured outcomes, not delivery: reconciliation and reporting shrank from 2–3 person-days to hours, N:N match rate ≥ 90%, and unmatched items were auto-classified. Value is "used," not "delivered and done."
变革领导力Change leadershipKEY SKILL
系统不是交付完就完。当 SME 看到草案真的长成能跑的系统，信任建立，业务开始主动反哺——「能不能加个 IC 预警」「待抵扣能不能自动跟踪」。这就是从「被交付」到「共创」的转变。A system is not done at handoff. Once SMEs saw the draft grow into a running system, trust followed and the business fed back proactively — "can we add an IC alert?", "can pending deductions be tracked?". That is the shift from being delivered to, to co-creating with.
务实的 AI 能力Practical AI fluencyKEY SKILL
AI 我用在刀刃上：Copilot in Excel 做高效提示与验收提速；但核心对账我刻意用纯规则校验而不上模型——月结第一要务是可靠，我不拿幻觉冒险。技术选型跟业务价值走，不跟时髦走。I apply AI where it earns its keep: Copilot in Excel for effective prompting and faster validation; but I deliberately kept the core reconciliation on pure rules, not a model — month-end reliability comes first, and I will not risk hallucination. Technology follows business value, not hype.
② 对准 SUGGESTED QUALIFICATIONS · 从发现到被采纳② Aligned to SUGGESTED QUALIFICATIONS · discovery → adoption
我这么说I say这个岗位要的是「从 discovery 一路带到 adoption」的证据。我这个 VAT 项目正好是完整闭环：场景挖掘（深入一线盘点月结困局）→需求定义（Draft Demo + Master 规则库）→落地（Fabric 流水线 + 撮合引擎）→效果验证（错误明细 / 匹配率 / 周期时长）→方法论沉淀（FDE playbook）。每一个环节我都是「能交付」的人在场，不是只画图。This role wants evidence of leading work from discovery through adoption. My VAT project is exactly that loop: scenario mining (front-line discovery of the close bottleneck) → requirement definition (draft demo + master rule library) → delivery (Fabric pipeline + matching engine) → effect verification (error details / match rate / cycle time) → methodology consolidation (FDE playbook). I was present at every step as someone who can deliver, not just draw.
③ 对准 WHAT TO RECRUIT FOR · 避免纯顾问 / 纯技术③ Aligned to WHAT TO RECRUIT FOR · avoid pure consultant / pure technologist
我这么说I sayJD 说得很直白：不要「只会交付的顾问」，也不要「框不住业务的纯技术」。我两头都占——业务出身能框问题，又亲手写了 PySpark 撮合引擎、优化过 T-SQL 视图，是能落地的人。判断力、owner 意识、赢得 SME 和高管信任，我的方式是「先给业务一个能跑的 Demo，用结果赢信任」，而不是用职位去压。The JD is frank: avoid "pure consultants who can't deliver" and "pure technologists who can't frame the business problem." I sit on both sides — business-native enough to frame the problem, yet hands-on enough to have written the PySpark matching engine and tuned T-SQL views, so I can land it. For judgment, ownership and earning SME/executive trust, my approach is "give the business a running demo first and win trust with outcomes," not with title.
④ 可能的追问 & 应对④ Likely follow-ups & responses
Q：业务自己都说不清规则，你怎么定义问题？Q: The business can't articulate the rules — how do you define the problem?
A：我不等他们说清，直接用带真实数据流的 Excel Demo 逼出来。模糊口径放进 Demo 里，业务一眼看出哪里不对，反对意见就是规则。我的经验是——「看得见的草案」比「抽象的需求」更能挖出真相。A: I do not wait for clarity — I force it out with an Excel demo wired to real data. Put the fuzzy definition in the demo, the business sees what is wrong at a glance, and the objections become the rules. My experience: a "visible draft" surfaces truth better than an "abstract requirement."
Q：为什么核心对账不上模型，AI 是不是只拿来凑数？Q: Why is the core reconciliation not on a model — is AI just there for show?
A：月结对账第一要务是可靠性，纯规则校验的可解释性我敢背；AI 我用在刀刃上——Copilot in Excel 做提示和验收提速。技术选型跟业务价值走，不跟时髦走。A: Month-end reconciliation is first and foremost about reliability; I can vouch for the explainability of pure rules. AI I apply where it earns its keep — Copilot in Excel for prompting and faster validation. Technology follows business value, not hype.
提示Note逐字稿里的数字（2–3 人天 / 约 10 家 / ≥ 90% 等）仍为草拟口径，背稿前请用真实数据替换（见《项目数据核对清单.md》），原文不要照念。Numbers in this script (2–3 person-days / ~10 entities / ≥ 90%) are draft placeholders — replace with real figures before memorising (see 项目数据核对清单.md); do not read them as-is.