Werkvertrag 与 Dienstvertrag：“Dienstleister”这个词到底让供应商承诺了什么

快速结论：Werkvertrag 约定一个明确的结果。劳动法意义上的 Dienstvertrag 约定在个人从属关系下提供劳动，freier Dienstvertrag 则适用于独立性更强的持续劳动。"Softwaredienstleister"只是营销标签。价格、范围、客户配合、变更和完工条款共同决定估算与交付风险如何实际分配。

这是一篇关于法律机制的文章，不是法律意见。真实合同我们与一位奥地利商法律师合作。这里给的是概念地图，好让你能带着尖锐的问题去找自己的律师，而不是花钱让律师解释基础知识。

Werkvertrag 和 Dienstvertrag 有什么区别？

奥地利法律主要按约定的义务和工作的独立程度区分这些模式。Werkvertrag（ABGB §1165 及以下）约定一份明确的成果，承包方通常独立组织工作，并对符合合同的结果负责。劳动法意义上的 Dienstvertrag 约定在个人从属关系和组织融入下提供劳动。两者之间是 freier Dienstvertrag，约定持续劳动，但个人从属性较低或不存在。WKO 对奥地利工作形式的比较解释了这些区别。付款不会仅因正式验收而自动到期：根据 ABGB §1170，除非合同或适用惯例另有规定，报酬通常在工作完成后到期。

德语里表示供应商的日常词 Dienstleister，与 Dienstvertrag 同一词根。这是语言上的巧合，不是法律上的：Softwaredienstleister 可以按 Werkvertrag 签约，而且通常就是这样。但这个巧合有影响，因为它把买方推向按努力评估供应商（日费率、人头、可用小时），而他们真正需要评估的是一个结果承诺。

买定制软件时为什么这很重要？

因为这些合同回答的问题不同，只有 Werkvertrag 以明确成果是否产生并符合约定为核心。在设有上限的固定费用下，承包方通常承担更多估算风险。但 Werkvertrag 本身并不会让每一次超支都自动由承包方承担：约定价格、成本估算、客户配合、范围定义和变更机制仍然重要。例如，ABGB §1170a区分有保证和无保证的成本估算。在基于劳动或时间的合同中，客户通常承担更多开放范围风险。两种模式本身都不代表不诚信，书面条款决定了大部分实际风险分配。

这也是为什么跨这两类比较日费率毫无意义。挂在努力义务上的较低时薪，并不比挂在结果义务上的较高费率更便宜，就像更便宜的彩票并不比债券更便宜。你在给不同的金融工具定价。围绕它的模式选择写在软件构建模式里。

"Softwaredienstleister"意味着供应商按 Dienstvertrag 工作吗？

不是。Softwaredienstleister、Softwareagentur、软件服务提供商和软件开发合作伙伴是同一类公司的营销标签，而其中大多数在范围明确的工作上都按 Werkvertrag 签约。标签本身不说明合同。在第一次通话中就明确询问合同类型，并把含糊的回答当作一种信息。

真正指向不同东西的标签是 IT-Dienstleister 或 Systemhaus。那是另一门生意：按 SLA 运维你现有的 IT，它确实建立在持续服务合同加可用性承诺之上。如果一份短名单把两个类别混在一起，提案将无法比较，而这通常是需求说明发错地方的第一个信号。

"问清楚：如果估算错了，供应商欠你什么。答案就是合同类型，无论网站把这家公司叫什么。"

Werkvertrag 究竟让我们承诺了什么？

一份确定的 SoW，对应一笔确定的费用。如果我们判断错了复杂度，成本由我们吸收，不会因为自己判断失误而额外开票。Werkvertrag 不意味着日期延误就退款：这个词的意思是在法律上有义务交付约定的结果，客户的救济途径遵循通常的 Gewährleistung 路径，即改善、减价，严重情况下解除合同。里程碑计划和验收标准写在 SoW 里，好让双方都知道工作何时算完成。

什么时候基于努力的合同才是诚实的答案？

有三种情况，坚持要 Werkvertrag 是错的直觉：

1. 范围确实无法预知。纯研究，或者对接一个没有文档的第三方 API。在这里给出固定的结果承诺，是穿着合同外衣的赌博，而价格会带上风险溢价。
2. 你需要的是已经有方向的团队里的产能。那是人员扩充，把它硬塞进 Werkvertrag 会制造一种关于"谁决定做什么"的虚构。
3. 维护和小改动。带月度上限的retainer 才是随时待命和偶发调整的正确形态。

对于范围明确、固定费用确实有上限的构建，Werkvertrag 往往适合。它的定价模式那一面，也就是固定价格对比时间与材料，在奥地利 SaaS 的 Werkvertrag 与时间材料里单独展开。

Scheinselbständigkeit（假独立）的陷阱

如果一份合同名为 Werkvertrag，但实际工作状态是 Dienstvertrag，奥地利主管机关看的是实际状态，而不只看标签。ASVG §539a明确要求社会保险分类重视真实经济内容，而非外在形式。相关迹象包括每天接受指令、被规定作息、融入客户组织、缺少自己的经营基础设施，以及约定本人劳动而不是独立完成的结果。重新分类可能引发追溯性的社会保险和薪资税后果。具体判断取决于个案，应寻求针对事实的专业意见，而不是依赖单一清单。

对买方的实际结论很简单。如果你想要的是一个嵌在你团队里、听你指令的人，就诚实地按 freier Dienstvertrag 或雇佣关系来约定。不要因为文书更省事就把它包装成 Werkvertrag。在第一张发票之前问你的税务顾问和律师，而不是在收到稽查函之后。

完工和验收标准如何改变整场对话

正式验收流程对软件项目很有用，但它不会仅凭 ABGB §1167 自动产生。现行 ABGB §1167把工作缺陷请求权转向 §§922 至 933b 的一般质量担保规则。合同应分别规定交付、检查、缺陷通知、修补、如需要的默示验收，以及里程碑付款到期。验收标准最好写成结果和可观察行为。含糊标准会增加完工和缺陷争议，所以我们把这些标准作为 discovery 的明确产出。

基于劳动或时间的合同通常没有与结果挂钩的验收时刻，除非协议明确设立。批准通常依据工时记录或服务报告。购买产能时这很合适，但如果期待的是成品，就会错配。

签约前问任何供应商的五个问题

• Werkvertrag 还是基于努力的合同？如果答案需要超过一句话，再问一次。
• 如果估算错了，成本由谁承担？同一个问题，换成一种答案无处躲藏的问法。
• 验收标准是什么，由谁来写？没有清晰标准，完工和缺陷就更难证明与执行。
• 全额付款后源代码和知识产权归谁？要写进条款，不是写进销售材料。
• 变更请求如何定价，时间表如何调整？每一份真正的 Werkvertrag 都有这条款。用它，而不是悄悄扩大范围。

我们在实践中如何回答这些，写在我们的定制软件开发服务上。对于正是这种形态的构建，Bond Analytics 案例研究展示的是一次范围与结果都确定的合作，而不是租来的团队。