正式要求公司records之前，先把request做成可以经得起独立复核的样子。假设有人会问你两句：为什么需要这一类record？哪一条具体法律路径让你有资格拿它？ 一个纪律严明的request更容易判断、更容易协商，也不容易把“某个法定register”误写成“公司全部内部资料”。

下面是准备清单，不是全球统一inspection right说明书。

第1步——锁定你要records的具体公司

写准确legal entity name、incorporation jurisdiction，以及知道的话registration number。

如果交易涉及集团，不要写“集团records”。把ParentCo、Subsidiary A、Subsidiary B和相关vehicle分别列出。权利义务一般绑定legal entity，而不是品牌名字。

第2步——写清你当前的legal capacity

只写一行准确身份：“我是current stockholder”“我是director”“我是creditor”，或其他真实status。

不要默认以前的身份一直延续，也不要把几个角色混在一起却不说明哪一个支持request。

如果capacity本身有争议，把它列为第一个当地法律问题。

第3步——列出准确record categories

用table，不要只写“all books and records”。

类别可能包括constitutional documents、bylaws、shareholder register、shareholder resolutions、board minutes、committee records、accounting records、transaction agreements、valuations和communications。

这一步重要，因为statutory access范围可能比公司全部record universe窄很多。

第4步——每一个category都对应一个purpose

对每类record写一句它要回答什么问题。

例：“8月1–31日board minutes——用于确认8月14日asset sale是否获授权，以及通过了哪些resolutions。”

如果解释不出某一类为什么重要，先删掉，或放到secondary list。

第5步——发demand前先确定legal mechanism

问当地律师：依据的是corporate statute、director governance right、contract、shareholder agreement、court disclosure、regulatory process还是其他机制？

不同mechanism不要混。statutory inspection demand可能有formal elements，informal board request没有；litigation disclosure的scope又可能完全不同。

第6步——如果依赖Delaware §220，核当前法条

现行DGCL §220定义特定books-and-records类别，并在法定条件下提供stockholder demand框架。

让Delaware counsel确认current standing、purpose、form、scope和procedure。不要拿旧template直接复制，而不检查amendments和current case law。

最重要的是，不要把§220写成“自动拿所有emails和files”。

第7步——如果依赖UK Companies Act §116，保持category准确

section 116针对的是register of members的inspection/copy，并要求request提供指定信息，包括purpose。section 117继续规定company response route；sections 118–119涉及refusal/default和misuse相关问题。

不要引用section 116来要求“全部corporate books”。

如果你需要英国其他record category，必须找独立法律基础。

第8步——加拿大联邦公司要区分§20的不同records

CBCA section 20(1)列明若干corporate records；section 20(2)另外要求accounting records以及directors/committee minutes和resolutions。

section 21(1)在其法定条件下针对的是section 20(1) records。不要把这句话悄悄延伸成对全部section 20(2) records的自动access。

想拿其他类别，应让加拿大律师确认requester还有什么其他rights/procedures。

第9步——给出可辩护的date range

一笔上个月才批准的交易，一开始就要求十年records，可能明显过宽。

从event chronology开始：negotiation、board circulation、meeting、approval、closing、immediate follow-up。如果后面发现更早决定或pattern，再扩。

清楚date range能减少review成本，也让“pure burden”式拒绝更难，但legal entitlement仍要单独判断。

第10步——preservation track与access track分开

如果有合理理由担心records会消失，先处理preservation，但不要假装“保存义务”等于“交付义务”。

识别systems、custodians和device turnover，措施要合法、合比例。privacy、privilege、employment、data rules都会影响实施。

公司完全可以先把record保住，同时继续争论是否应当production。

第11步——尽早识别privilege、privacy和confidentiality

不要等production当天才发现里面有legal advice、personal data、trade secrets或third-party restrictions。

把可能受保护类别先标出来，问当地法怎样处理。答案可能是exclude、redact、undertaking、confidentiality agreement或court direction。

“confidential”不自动等于“永远不能access”，但确实需要protection plan。

第12步——保护provenance

provenance重要时，应当取得native records或不会抹掉关键metadata的可靠copy。

minutes/resolutions要区分draft、approved、signed版本；board portal如果能看到distribution history，也应保存；spreadsheet在相关时记录creation/modification history。

证据问题经常不仅是“文件写了什么”，还包括“什么时候存在、谁当时拿到了”。

第13步——用真正legal route决定response clock

不要自创全球统一“7天期限”。

有些statute明确规定response period；contract可能另有时间；court procedure也不同。比如UK section 117对section 116 request有自己的response framework，其他路径完全不一样。

使用正确当地时限，并另外标出transaction closing或litigation deadline。

第14步——提前定义“可以接受的partial response”

records dispute不一定非黑即白。

公司可以先给无争议records，对其他类别保留objection；requester也可以接受staged production，只要高优先级先来；confidentiality问题有时通过protective terms解决。

先定义下一次决定最低需要哪些信息，避免双方为低优先级材料彻底卡死。

第15步——升级前做refusal matrix

如果被拒，先分类理由：

  • requester没status；
  • purpose被争议；
  • category不在引用statute；
  • scope过宽；
  • record不属于这个entity；
  • confidentiality/privilege问题；
  • procedural defect；
  • 公司没有清楚理由就拒绝。

不同refusal需要不同反应。能纠正的程序问题先纠正，不要一上来就把它变成litigation。

第16步——把access dispute和merits dispute分开

你可能因为怀疑related-party transaction而要records，但两个问题不完全相同。

拿到access不等于证明交易wrongful；某一次access request失败，也不证明交易proper。

建议分两个file：一个放entitlement/access，一个放underlying governance issue。

第17步——记录实际production了什么

建立production index：category、date range、source、format、production date，以及任何withholding basis。

这样可以避免重复索取同样资料，也会把真正gap暴露出来。独立顾问也能快速看出production是否回答了原purpose。

第18步——根据gap决定下一步，不要根据情绪升级

production之后问：哪个关键问题仍然没有答案？

如果missing item很核心，而且legal entitlement很强，升级可能合理。如果只是边缘资料，可能应该用现有evidence继续推进。

不要只是因为production过程令人恼火就去诉讼。

发出前总清单

正式records request前确认：

  • correct entity；
  • correct requester status；
  • exact legal mechanism；
  • record categories定义清楚；
  • purpose真实；
  • date range合理；
  • category-to-purpose link已写；
  • preservation单独处理；
  • privilege/privacy/confidentiality已考虑；
  • current statute/amendments已核；
  • response timetable已确认；
  • next irreversible event已标；
  • staged production可接受范围已想好；
  • escalation route由当地律师确认。

如果还有好几项空白，request大概率还没准备好。

高质量request听起来是什么样

它具体，但不会在尚需当地法律意见的地方装作绝对确定。它说清entity、status、purpose、records和date range；不会写“shareholders have a right to all records”这种全球化口号；只引用真正适用的mechanism，并保留随着evidence发展合理调整scope的空间。

这种组合——事实聚焦、法律基础准确、证据被保存、下一步决定清楚——才能让record access变成真正治理工具，而不是无边界document war。

本文仅提供一般公司治理信息，不构成法律意见。董事义务、查阅权、程序和救济会因法域、实体类型和事实而显著不同；采取行动前应由当地合资格专业人士核对现行法律、治理文件与时限。

相关阅读

来源与适用边界